Re: i37 - Vary and non-existant headers

Just been reading the old discussion on issue i37 and thought I'd throw 
in my 2c on this, since I'm currently re-writing our caching module.

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.

However for Accept-Encoding, I believe this is an advertisement of 
capability by the client, and absence of this advertisement should be 
taken to mean the capability isn't there, and therefore this is a 
non-match. (PS, this is another instance of where a reference to the 
"identity" coding should be removed).  There is also explicit wording 
for how to deal with a missing header in this case also which disagrees 
with me - states that "the server MAY assume that the client will accept 
any content coding".  This however IMO is dangerous, and the SHOULD 
requirement to send "identity" should be replaced by MUST send 
unencoded.  Otherwise we are making gzip, deflate etc all mandatory.

Also, for Accept-Charset there is explicit mention of how to determine 
default values.  It explicitly states that the lack of an advertised 
restriction is deemed to be no restriction.

PS, a gripe about "q" values.  Surely it would have been a lot simpler 
to just get the UA to specify the preference by the order, e.g.

Accept-Language: en-nz, en, fr, *

This clearly indicates a preference for NZ English, followed by any 
other English, followed by any French, followed by anything else.  
Absolute quality shouldn't factor in the server's decision (it 
contravenes client's advertised willingness to accept something), only 
relative quality, and that is ranking.  I guess this wouldn't cover the 
q=0 case, but absence of advertised acceptance should be taken as lack 
of willingness?  And the use case for accepting a range of things, and 
denying part of the range, whilst plausible, makes me wonder if anyone 
uses it.

In terms of how this affects the spec, what about in these Accept* 
headers, allowing a list of accepted values to be interpreted as a 
priority list where no q values are present.

Adrien






-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 14 November 2007 04:10:36 UTC