- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Sun, 16 Mar 1997 14:16:44 -0500
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http-wg@cuckoo.hpl.hp.com
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 -- 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