Darryl L. Miles wrote:
Mark Leone wrote:
It's a silly problem. I ran in to it a while back, and it really
mystified me until I found the bug write-up. Tomcat is doing the
right thing, but MS has declared that IE is working "as designed" in
this. FWIW, the HTTP spec is clear that the no-cache behavior applies
to HTTP intermediaries, not user agents.
"the HTTP spec is clear that the no-cache behavior applies to HTTP
intermediaries, not user agents."
Are you really sure ?
I have always understood the HTTP 1.1, "Cache-Control no-cache"
response header to be able to control both intermediaries and user
agent caching activities.
The specification does not talk in terms of user agent caches and
intermediary caches it only talks in terms of caching operations (for
the large part) with a few additional directives to target
shared-public and/or private cache behaviour.
Yes, my comment was imprecise. I should have said that the HTTP spec is
clear that the no-cache behavior does not apply to user agents in the
way that it is implemented in IE. Having said that, reference your two
statements about re-use:
As there is no differenciation between shared-public and private
caches when it comes to the "no-cache" directive, all caches must
revalidate the request before subsequent reuse... The important point
of "no-cache" is your HTTP client must ask the server before you
re-use your cached object, its upto the server to then say "No! Here
use this instead".
This is precisely the issue with IE. The failure to make the resource
available to the user does not occur on a request for re-use. I agree
that the spec can be read to indicate that a no-cache directive should
mean that the user agent serves the resource once and then requests
re-validation from the origin server for any subsequent requests for the
same resource.
But that's not what causes the subject error condition. The user
requests a resource, and IE says essentially the following:
"Because of the way I've been implemented, I have to store this resource
temporarily in order to show it to the user. Now that means I have to
cache it... Oh, I just noticed, this resource has a no-cache directive
in the header. I can't store this in cache... [forgetting the actions
just taken] Hey, where's that resource I just copied into cache? I don't
see it. The web site must be unreachable. That's what I'll tell the user."
The point is that IE is not providing the resource to the user *the
first time* because there is a no-cache directive associated with it.
IMO there is noting in the HTTP spec that even hints that this is how
the no-cache directive is to be used. If IE needs to temporarily store
the resource in order to provide it to the user, and a no-cache header
is present, then it should find a way to give it to the user without
caching it (which of course is not the same thing as temporarily storing
it for spooling purposes), instead of refusing to let the user see it
the first time the server sends it, and then hiding behind the HTTP spec
to justify a poor implementation.
I think the end result speaks for itself. What possible use could a
no-cache directive have if it means that user agents can't even give the
resource to the user the first time it's requested? If this is really
what the spec means, then every non-cacheable resource on the web is a
self-licking ice-cream cone. Probably tastes great, but no one will ever
really know. All the other user agent implementers seem to have
interpreted the spec appropriately, without failing to give the users
the resource the server explicitly provided to them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
