Re: Rethinking content negotiation (Was: rethinking caching)

>>I like this syntax. The URI header would work, but this is short and
>>to the point.

>I think this syntax is insufficient.  This is pretty much the information
>that was contained in the HTTP/1.0-01 draft (AKA HTTP/1.1 before there was a
>1.1) and it was presumably changed because others felt likewise.  Using that
>scheme would require that the caching proxy keep the exact header(s) stored
>for the specified vary quanity for comparison purposes.  This is a huge
>burden on a proxy because it doesn't just have to save headers once, it has
>to save headers for each request that doesn't have the exact same paramters
>as previous requests.

Firstly, I'm not convinced that it's a _huge_ burden; does anyone have
any statistics on Accept: headers?

>An example might be useful here, if not longwinded.  This demonstrates the
>insufficent-ness of the old URI:, and a Vary: header scheme as well.
>...
>[Example of Accept: header]

Yes, there are cases where a Vary: header will not provide enough information
for a cache. But are you arguing against the implementation of the
Vary: header? I am suggesting that it is a useful feature for varying
resources. You seem to be arguing that it may not be enough for caching
of content-negotatiated resources. Does that matter?

>...
>(I completely ignore the vary by User-Agent here, but until we invent the
>psychic proxy, no proxy can solve for server's varying content outside of the
>content negotiation scheme without listing all 2000 user agents that come
>through its doors.)

I'm not quite sure what you mean, but half of the point of the Vary: header
was to inform about the server's varying content outside the content
negotiation scheme.

 David Robinson.

Received on Thursday, 21 December 1995 09:52:51 UTC