------_=_NextPart_001_01BF519A.4A20DA86
Content-Type: text/plain
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU]
> Sent: Tuesday, December 28, 1999 11:58 AM
> To: Dan Kohn
> Cc: 'fahrner@pobox.com'; Fork (E-mail); 'www-style@w3.org'
> Subject: Re: IE 5.0 stylesheet caching bug
>
> That is because the URL being used for the stylesheet is negotiated,
> which results in a Vary header field being returned by Apache, which
> for some incredibly stupid reason MSIE refuses to cache even though
> its user agent is based on a non-shared cache.
Actually, this isnt true.
First, what exactly is a non-shared cache ?
There are at least 3 shareability issues.
1) user ( only this user gets this cache)
2) application (only this app has access to this cache)
3) session (only this session (browser window?) has access)
In IE's case, the cache is always shared among
different #2 and #3, and sometimes shared by different #1.
Puttin aside #1, its obvious that you should configure
IE to keep different users cache's separate, and this is
the default.
In windows, the User-Agent is separate from the cache and
HTTP driver. Typically, many applications running in the
users context will call the system APIs for HTTP like
InternetOpenFile(http://foo/bbar).
Since the app isnt required to give accept: information
to the http stack, its difficult to know when to re-use
a resource in the cache.
Thus, vary ends up being no-cache. (just like every
other known implementation of vary :)
Certainly, wininet could require apps to give
content negotiation or accept information before
returning content. However, this complicates things
considerably, both in the implementation of the stack
as well as the lives of developers who just wanted a simple
API to deal with the web.
Im not saying that we did the perfect solution with the
utmost flexibilty, but for the majority of customers
(eg developers and users), I think we did them justice.
So, thats the :
"incredibly stupid reason MSIE refuses to cache even though
its user agent is based on a non-shared cache."
------_=_NextPart_001_01BF519A.4A20DA86
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ICS.UCI.EDU]
> Sent: Tuesday, December 28, 1999 11:58 AM
> To: Dan Kohn
> Cc: 'fahrner@pobox.com'; Fork (E-mail); 'www-style@w3.org'
> Subject: Re: IE 5.0 stylesheet caching bug
>
> That is because the URL being used for the stylesheet is negotiated,
> which results in a Vary header field being returned by Apache, which
> for some incredibly stupid reason MSIE refuses to cache even though
> its user agent is based on a non-shared cache.
Actually, this isnt true.
First, what exactly is a non-shared cache ?
There are at least 3 shareability issues.
1) user ( only this user gets this cache)
2) application (only this app has access to this cache)
3) session (only this session (browser window?) has access)
In IE's case, the cache is always shared among
different #2 and #3, and sometimes shared by different #1.
Puttin aside #1, its obvious that you should configure
IE to keep different users cache's separate, and this is
the default.
In windows, the User-Agent is separate from the cache and
HTTP driver. Typically, many applications running in the
users context will call the system APIs for HTTP like
InternetOpenFile(http://foo/bbar).
Since the app isnt required to give accept: information
to the http stack, its difficult to know when to re-use
a resource in the cache.
Thus, vary ends up being no-cache. (just like every
other known implementation of vary :)
Certainly, wininet could require apps to give
content negotiation or accept information before
returning content. However, this complicates things
considerably, both in the implementation of the stack
as well as the lives of developers who just wanted a simple
API to deal with the web.
Im not saying that we did the perfect solution with the
utmost flexibilty, but for the majority of customers
(eg developers and users), I think we did them justice.
So, thats the :
"incredibly stupid reason MSIE refuses to cache even though
its user agent is based on a non-shared cache."