Re: X-Vary-Options patch

On sön, 2008-06-08 at 11:23 +1000, Mark Nottingham wrote:

> That doesn't take care of the qval problem, but it helps in the accept-
> encoding case, which is the most common (I don't often see qvals on a-
> e; anybody?).

Not on Accept-Encoding, but quite often on Accept-Language.

> One of my concerns about X-Vary-Options (can we please
> drop the 'X-'?) is that there are non-obvious corner cases; it forces
> the origin server admin to think very carefully about all the
> different variants that they're going to issue, and the request
> headers that will match them. If we can get rid of the common cases by
> canonicalisation, they will have less opportunity to mess things up.

Agreed.

> Also, it's important to realise that at some point it's more
> worthwhile to take an approach like TCN and describe the available
> variants, rather than match against selecting headers.

Yes, what I said..

To make this work "as intended by admins" without excessive roundtrips
the cache needs to know the available variants and their priority,
allowing the cache to perform the Accept-* logics itself to see if the
response is acceptable.

Yes, by pathing up and sorting Accept-Encoding can be cut down to a
quite acceptable level even without this. But it's harder for
Accept-Language or other Accept* headers where there is more diversity.

A gentle reminder for those not familiar with the problem: Vary in HTTP
is very blunt and only says "I looked at these headers to determine what
response to send, so this response is only valid for any request having
the exact same content in those headers", but for many situations this
is sub-optimal as those headers can be send in a wide variety of
different manners which all yield the same result. For a gzip encoding
server the following Accept-Encoding variants is all equal: "gzip",
"gzip, deflate", "deflate,gzip", "deflate, gzip", "x-myencoding, gzip",
"deflate=0, gzip". "gzip=1, deflate=0.5". But the following is very
different: "gzip=0, deflate"

By sorting and canonicalisation it can be cut down to

   "gzip"
   "gzip, deflate" ("gzip, deflate", "deflate,gzip", "deflate, gzip")
   "x-myencoding, gzip"
   "gzip, deflate=0"
   "gzip=1, deflate=0.5"

And by special casing it can be further cut down to

   "gzip" ("gzip", "gzip, deflate", "deflate,gzip", "deflate, gzip", "gzip, deflate=0", "gzip=1, deflate=0.5", "x-myencoding, gzip")

based on the special casing that gzip is far mor common than deflate,
and that content-encodings are fully interchangeable for implementaitons
supporting both.

Regards
Henrik
Received on Sun Jun 08 2008 - 13:27:23 MDT