.asp pages and cache

[Scott]

Jeff,


Thanks for your message.

We have since encountered another situation where our caching is 
resulting in the incorrect page being displayed after a 302 redirect.  I 
have added this second case and your message to the bug report that we 
have on this and I think I can safely say that we will modify our 
behavior here to be compatible (though I don't make the final decision I 
think there is a good case for it).

Regarding compressed encodings (like gzip) we did have this 
functionality in OmniWeb, but we had to remove it because of some nasty 
bugs that it was causing.  We do plan to support this again; the HTTP 
spec requires UA's to know how to deal with this.


Sincerely,


Scott
Support Engineer
Omni Group


On Wednesday, June 19, 2002, at 09:20  AM, Jeff Moore wrote:

> Good job on passing the http://www.procata.com/cachetest/ tests. Thanks.
>
> On my "POST Location" test, there is a note about this case.
>
> I agree that Omniweb is technically correct in this matter.  I very 
> much wanted to write a test that would not allow the destination of 302 
> requests to be cached, but as you point out, there is nothing in the 
> specification to support that.
>
> So, I make an appeal to the elastic clause of the the caching chapter, 
> "semantic transparency."
>
> I think a 302 should trigger a re-read of the URI in the Location 
> field.  If only because thats what IE and NS do and most developers 
> don't go beyond that in testing.
>
> The 302 is commonly used to re-direct back to a page which has already 
> been viewed after the values on it have been changed on a different 
> page.
>
> Caching these requests is like not avoiding an accident because you 
> have the right of way.
>
>
> PS
>
> Now that the caching looks good, I'm going to start pestering you guys 
> to support compressed encodings.  :)
>
>
> On Monday, June 10, 2002, at 07:24  PM, Scott wrote:
>
>> I logged in here and was able to reproduce what you describe.  Each 
>> one of the game links that you click has a very unique URL (GET 
>> /ttn/game.asp?id=1816&GUEST=1) but is then redirected by the server to 
>> a different URL:
>>
>> Jun 10 15:34:57  http Rx: HTTP/1.1 302 Object moved
>> Jun 10 15:34:57  Location: guest.asp
>>
>> Then you hit the back button, choose a different game, and we go 
>> through the same process again; making the request and then being 
>> redirected to guest.asp which we have in our cache and so we show that 
>> page.
>>
>> The pages that come from the server have nothing in them or the 
>> headers that would indicate to us that it should expire at a specific 
>> time or that we should be making a new request for the page when later 
>> redirected to the same URL.
>>
>> For a technical reference you can see the HTTP 1.1 spec, section 
>> 10.3.3 302 Found, at this URL:
>>
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>>
>> Mentioned there for a 302 is the following: "This response is only 
>> cacheable if indicated by a Cache-Control or Expires header field." 
>> and we are not caching the redirect response, just the response to the 
>> request for the document at the redirected URL.
>>
>>
>> If you can provide some reason that we should not be behaving this way 
>> then we'd certainly consider modifying our behavior but it seems to me 
>> that we're doing things right here.  You might want to contact the 
>> people who run this site and see what they have to say about this.
>>
>> We recently modified our caching behavior to be more compatible with 
>> dynamic pages, as the tests here show (We pass them all):
>>
>> http://www.procata.com/cachetest/
>