semantically equal (Was: source quality, caching, and Vary:)

]
] >Based on these examples, am I correctly understanding how Vary: is
] >supposed to work?
]
] Yes and no.  For the request/variant scenario you listed a server SHOULD NOT
] BE USING VARY:  Sorry to shout, but I want it to be real clear.  Vary: is
] strictly for those cases where it's hopeless or excessively complicated for
] a proxy to replicate what the server would do (other than storing header and
] doing strict request header equality comparisons on subsequent requests).

I understand -- no need to shout :-) I just didn't want to type in an 
example complicated enough to warrant using Vary.

] >If so, then I think that for completeness the Vary: proposal  needs to
] >specify what "semantically identical" means for each of the header
] >values that can vary, because for at least some of them, it isn't
] >trivial, as I hope the above example shows.
]
] I would think semantically equal would normally be implemented as strcmp().
] Or maybe a homegrown strcmp() that ignores LWS.

And comments. (Technically a form of LWS, I suppose, but makes the 
homegrown strcmp() a little more complicated -- only some headers 
accept comments.)

] An excessively courageous
] proxy could special case the Accept-* headers, and actually go through the
] trouble of matching "Accept-Language: fr ; q = 0.9, en" to "Accept-Language:
] en,fr;q=.90" I suppose.

The operational definition of "semantically equal" in the case is 
"would not cause the server to select a different variant".  And that 
may require a more careful analysis of each header than we've done to 
date. We may want to restrict the set of headers that can Vary: to the 
set for which "semantically equal" has been defined. And that may make 
new headers, about which the cache knows nothing, problematical. In 
general, a strict strcmp() should be OK, but there might be wierd cases...

Paul

Received on Wednesday, 14 February 1996 02:12:29 UTC