Re: ETags vs Variants, was: Revising RFC2616 - what's happening

fre 2006-10-20 klockan 23:02 +0200 skrev Julian Reschke:
> Henrik Nordstrom schrieb:
> > fre 2006-10-20 klockan 20:46 +0200 skrev Julian Reschke:
> > 
> >> Right. So we don't want the cache to serve the cached response in 
> >> absence of the request header, right?
> > 
> > Only if it has a matching request/response pair from a request absent of
> > the header.
> 
> I think I disagree. Maybe it's really time to come up with either 
> pseudocode or precise formal definitions.

The "set of headers" approach mentioned resently is very easy to work
with.


Assuming a "Vary: Accept, Accept-Encoding"

GET / HTTP/1.0
Host: www.example.com

Cache key:
http://www.example.com  Vary Headers: {}


GET / HTTP/1.0
Host: www.example.com
Accept:

Cache key:
http://www.example.com  Vary Headers: {{Accept-Encoding: }}


GET / HTTP/1.0
Host: www.example.com
Accept: */*
Accept-Encoding: gzip

Cache key:
http://www.example.com  Vary Headers: {{Accept-Encoding: */*},
{Accept-Encoding: gzip}}


Absent headers only matches absent headers. Present headers only matches
present headers with the same canonical value. End.


It multiple Vary values per URI is supported by the cache then Vary as
such also need to be included in the cache key, and very careful design
to not allow out-of-sequence cached responses.


See 13.6 which among other things says

   The selecting request-headers from two requests are defined to match
   if and only if the selecting request-headers in the first request can
   be transformed to the selecting request-headers in the second request
   by adding or removing linear white space (LWS) at places where this
   is allowed by the corresponding BNF, and/or combining multiple
   message-header fields with the same field name following the rules
   about message headers in section 4.2.

which is quite unambiguous in how to compare the requests. Not sure it's
possible to define this more clearly.

Regards
Henrik