- From: Daniel DuBois <ddubois@rafiki.spyglass.com>
- Date: Mon, 11 Mar 1996 14:59:39 -0600
- To: Paul Leach <paulle@microsoft.com>, fielding@avron.ICS.UCI.EDU
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
paulle@microsoft.com said: >fielding@avron.ICS.UCI.EDU said: >] Given that a Variant ID also needs a Validator in order to be useful, >] wouldn't it make more sense just to require that the validator contain >] the equivalent of a Variant ID when variants are present? > HTTP/1.0 200 OK > Content-ID: "xxxxx" >How does the cache know if the two "foo.txt" are variants of one >another, or if the one-and-only "foo.txt" has changed? The presence of a "Vary:" header, ie: HTTP/1.0 200 OK Content-ID: "xxxxx" Vary: Foo-Header [I think under the David Robinson Vary: header proposal, there's a mechanism for Vary: random-whenever-I-feel-like-it-not-on-any-header, which is effectively "validate every time" AKA Cache-control: max-age=0 ?] We still have the question of what does a caching proxy do when it just keeps validating and getting new Content-ID:s + Vary: every time on the same URL. Does it continually append "If-ID: id1, id2, id3, id4, id5...." ad infinitum on later responses? The idea of Expires: foo, or Cache-control: max-age=foo is to indicate when things need to be validated, not when caching should flush old stuff. Obviously, on a non-Vary:ing resource, the proxy would just replace a cached entity if it got a new thing, but here, the flushing of an old item on the receipt of a new one is not implicit. So is the flushing of id1 purely an implementation issue (probably) or.. In "http://weeble.lut.ac.uk/lists/http-caching/0114.html" Dan said: b) Does the proxy still store the other non-matched variants? c1) Do we need to give the server a way of saying "clear all your variants"? c2) Do we need to give the serve a way of saying "clear these particular variants"? (Presumably they'll clear eventually anyway as the proxy runs out of space and/or pushes them out of their working set.) e) What about renegade proxies who serve variants willy-nilly without contacting the server? etc... >I think that you're right that we can condense the number of headers. >One suggestion: add an "id=" parameter to Content-ID, and allow >multiple validator/id pairs on IF-ID and Unless-ID. Then the above would be: > Client Server > GET /foo.txt HTTP/1.1 > HTTP/1.0 200 OK > Content-ID: "asdasfa";id=1 > GET /foo.txt HTTP/1.1 > HTTP/1.0 200 OK > Content-ID: "xxxxx";id=2 > GET /foo.txt HTTP/1.1 > IF-ID: "asdasfa";id=1, > "xxxxx";id=2 I don't mind this suggestion because I think it will be clearer to protocol implementors. Someone else might complain about the non-opaqueness of it. I do still think you need the Vary: header however - the presence of "id=" doesn't convey enough information. ----- Dan DuBois, Software Animal http://www.spyglass.com/~ddubois/ Download a totally free copy of the Spyglass Web Server today! http://www.spyglass.com/products/server_download.html
Received on Monday, 11 March 1996 13:06:35 UTC