.asp pages and cache

[Jeff Moore]

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/