Re: Caching dynamic pages (CGI) for one service/server

"Nottingham, Mark (Australia)" wrote:
>
> > Last paragraph of section 13.9.
>
> Hmm. It's a bit ambiguous (big surprise). First it says that query URLs
> shouldn't be treated as fresh unless they have expiration, and then goes on
> to specify that responses from 1.0 servers for these urls should not be
> taken from the cache.
>
> "treated as fresh" and "taken from the cache" are two different things;
> "taken from the cache" implies that it shouldn't be validated.

It's certainly a bit of a tangle.

> I know this is splitting hairs, but I have a specific application in mind.
> If someone has implemented validation on an object with a query string, and
> the server advertises itself as 1.0, they lose unless they specify
> expiration. Ah, well, it's a matter for the WG, perhaps. At least they don't
> say anything about /cgi-bin/.
>
> In practical terms, IMHO a cache shouldn't just mark all queries uncacheable
> willy-nilly; it discourages people from working to make them cacheable. I
> was very heartened to see that change in Squid 2.

I concur. I try very hard to make my query code return cacheable
objects. It's annoying when they don't actually get cached.

> > But we do need a way to specify cachability of objects
> > without any expiry information, to enable
> > selective caching of search engine queries and other
> > "read-only" scripts which does not provide any expiry information.
>
> If it doesn't have a validator, and it doesn't have any age hints, how can
> you? Matching a regex against the URL isn't going to catch all of the truely
> dynamic ones, and users getting incoherent results will IMHO cause a lot of
> trouble and bad press for caching.

I think the word you're looking for here is 'inconsistant'.

Consistancy of behaviour _is_ very important, I'll grant..Of course
sometimes you have to bend the rules a little to achieve it.
D
Received on Tue Jul 29 2003 - 13:15:58 MDT