- 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