tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Leone <>
Subject Re: IE-Page not found problem
Date Tue, 14 Jun 2005 03:53:42 GMT
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:
For additional commands, e-mail:

View raw message