Re: i37 - Vary and non-existant headers

Adrien de Croy wrote:
> If we don't take into account any meaning of headers, we lose many 
> opportunities to cache.

This is true, but that meaning is taken into account at the server.

It can still return a 304 Not Modified response, and the bulk of data
transfer is cached even though there's a round trip time.

If caches interpret headers in order to find more cache equivalents,
then it's _essential_ that this agrees with _all_ conformant servers,
including those already deployed, otherwise caching is not safe.

> E.g. if an original request for something contained an Accept-Language 
> header specifying many acceptable languages, the response comes back 
> with one of those languages.  If a subsequent request comes in which 
> will accept the language that is cached, should that be served back or not?

In that case, the request is sent to the server, which might decide to
return 304 Not Modified with the same Etag, and after that the cache
can server the entity without contacting the server for both forms of
the request.

> I guess there are difficulties there where for one request it was the 
> preferred language and for another it was a less-preferred language.
>
> In which case how would you compare Accept-Language tags?  You'd need to 
> compare them as a list with q values.  Or would you do it so that if the 
> q value was 1 in the original request and subsequent request then its ok 
> to return that one?:

No, because it's permitted to have a server whose policy differs from
what you're assuming, and in any way you haven't thought of.

For example, a server might decide that Engish with q=1 and Polish
with q=0.75 should be served the Polish version because the English
version is a poor translation of the Polish original.  You can't know
the server's policy.

If there was a real value in removing a round trip in these cases, a
cache extension could be defined, where the server returns something
like "Cache-control: accept-language-standard-policy", and there was a
standard policy.  That would permit the cache to apply the policy.

(I doubt if there would be much gained by that feature, because it
only helps the _first_ request with a different header than previous
matching requests).

> >The process is spelled out in quite detail in 13.2 Caching Negotiated
> >Documents, with very little room for error other than implementation
> >bugs. That's provided one cares to read 13.2 before jumping to
> >conclusions about how this should work.

And, indeed, a large number of server depend on caches behaving this
way.  It can only be changed by definining something in the response
which flags that additional rules may optionally be applied.

-- Jamie

Received on Thursday, 15 November 2007 21:26:11 UTC