W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: i37 - Vary and non-existant headers

From: Jamie Lokier <jamie@shareable.org>
Date: Wed, 14 Nov 2007 19:06:40 +0000
To: Adrien de Croy <adrien@qbik.com>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <20071114190640.GA4691@mail.shareable.org>

Adrien de Croy wrote:
> IMO the condition for a match depends on the meaning of the header.  In 
> general if a header in a Vary tag advertises a capability, and has any 
> possible values which are optional under the spec, then lack of the 
> header would need to be deemed a mis-match, otherwise the cache would be 
> assuming that an optional capability was available at the UA where it 
> was not advertised.  Where the header advertises a restriction, then 
> lack of an advertised restriction should be deemed lack of the 
> restriction.  Where the definition of the header explicitly states how 
> to handle lack of the header, then this overrides.
> 
> For instance, an Accept-Language header is a way for a UA to indicate 
> what languages it is prepared to accept.  Absence of this header IMO 
> indicates that the UA is prepared to accept any language, and that 
> therefore if a cached entity had "Accept-Language" in its Vary header, 
> then this would match.  An alternative view could be that absence of a 
> header implies a default value, e.g. English, and so if the stored 
> entity was not English, this would not match.  Personally I believe in 
> this case that lack of advertisement of a restriction implies lack of 
> the restriction.

What about a server generating something dynamic like this pseudo-code?

    <html><body>
    <? if (exists headers["Accept-Language"]) {
           print "Your request asked for these: ", headers["Accept-Language"];
       } else {
           print "Your request didn't specify any particular languages"
       }
    ?>
    </body></html>

That doesn't conform to the semantic equivalences you describe, but
it's valid and sometimes useful.

A result like that can be cached by putting Accept-Language in the
Vary header, and some systems would do that automatically, generating
the Etag and Vary header automatically from code like that.  (The Vary
header is generated due to seeing that header referenced in the page
logic.)

But if you say that a client or proxy can match a request with no
Accept-Language with a stored earlier request that has any
Accept-Language, then those dynamic response generation systems will
behave not as the programmer expects.  Some requests with no
Accept-Language will receive responses like "Your request asked for
these: <language>", which is clearly misleading.

That would require all systems which automatically make pages
cacheable by generating Vary headers to have knowledge of all header
semantic-equivalence rules, or declare that code in those systems
which doesn't fit those rules (like the example) is invalid and may
give misleading responses from caches, or always use Vary * which is
quite some overhead.

Note that there is no harm in a mis-match, and a mis-match is only
likely when requests are from differently configured clients.

As there's no harm in occasional mis-matches, and I think there is
some harm in preventing code like the example from working in a simple
automatic dynamic caching system, I propose that empty headers be
treated as distinct from present headers with any value, and that the
rules are the same for all headers, unless particularly good reasons
why that's a problem for a particular header can be shown.

-- Jamie
Received on Wednesday, 14 November 2007 20:20:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:23 GMT