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

Re: Variant IDs

From: Daniel DuBois <ddubois@rafiki.spyglass.com>
Date: Mon, 11 Mar 1996 14:59:39 -0600
Message-Id: <9603112059.AA05730@rafiki.spyglass.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:48 EDT