W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Suggestion: Add Cache-Control extensibility to Vary header

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Sun, 16 Mar 1997 14:16:44 -0500
Message-Id: <>
To: Koen Holtman <koen@win.tue.nl>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2680
At 07:21 PM 3/16/97 +0100, Koen Holtman wrote:

>In stead of 
> Vary: Protocol, "http://some.org/a-required-extension"
>you can just as well use
> Vary: Protocol
> Cache-control: vary-protocol="http://some.org/a-required-extension"
>or something, so there is no need to revise the Vary syntax: just use the
>extensible cache-control syntax to convey your extra directive.

This is not exactly what I am trying to achieve. It is not a question of
describing which parts (headers, body, or complete message) of a response
that are cacheble or not but rather under which circumstances an already
cached object can be returned from the cache in response to a request.

If we in the example I wrote in the previous mail let the required extension:

	http://some.org/a-required-extension {str "req"}

be a feature that supports round windows layout. The origin server then
says: "I will only give this to you if you support round windows" and uses
the Vary header to convey this information to any proxies in between.

What I want to avoid is that a client saying "I do support round windows
(required) and btw, if you feel like it, I can also do star shaped ones
(optional)" can't get a cached version simply because it has a slightly
different (and optional) profile.

Diversity is a virtue :-)

>You can also use the following hack, which will get you what you want even
>under the current HTTP/1.1 spec.  If you have multiple protocol headers but
>only want caches to vary on one, include an extra header like
>Proto-Vary: {http://some.org/a-required-extension {str "req"}}
>in the response, and send "Vary: proto-vary" in stead of "Vary: protocol".
>Strange, but fun.  Of course, you would usually want to have a shorter
>encoding in the above proto-vary header.

Throwing in random new headers is exactly what PEP tries to avoid so I
would be unhappy if this was the preferred interaction with existing
HTTP/1.1 mechanisms.

Thanks for your reply!


Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA
Received on Sunday, 16 March 1997 11:18:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC