Re: Variant IDs

----------
] From: Daniel DuBois  <ddubois@rafiki.spyglass.com>
] Date: Monday, March 11, 1996 12:59PM
]
] 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

Hmmm... first I thought you were right, then I thought you were wrong, 
now I think you're both right and maybe wrong.  You can indeed tell 
that what you got back is a variant from the fact that there's a Vary 
header in the response.  So you're right.  However, the Vary: header 
value is a _request_ header name. How do I match it up the Accept-* 
values in the Vary header with the Content-* entity headers in the 
response? I suppose I've saved the Accept-* headers in the request, so 
maybe that is what I use to see if there is already another instance in 
the cache.  But can't I have two different Accept-* configurations 
translate to the same entity?  E.g., the resource can vary on content 
language, but Accept-Language: for Japanese and Chinese might both map 
to English content, whereas French and German might have variants just 
for themselves. I think it can probably be done, but there might be 
gotchas -- having the origin-server just _tell_ the cache that it's 
variant number 23 would be a lot easier, and it saves transmitting the 
entity-body when you've already got it cached, even though it's got 
different Accept-* header values.

]
] [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.

Whereas, if there is a variant ID, you know what validator to overwrite.

]
] 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.

More precisely, it doesn't convey enough info to permit the cache to 
serve up a variant without a round-trip to the origin-server to get 
back at least the the variant ID of the entity to serve (and the entity 
iteself if it isn't in the cache or has changed). If the cache wants to 
be able to cut out tthat round trip, then it needs the information in 
the Vary: header (or Alternates: from Koen's proposal).

In this sense Vary and Content-ID are orthogonal. A really stupid cache 
could not use Vary and just go back to the origin-server to do all 
content negotitation, and still get the advantage of caching for all 
entity-bodies. In some cases, like when authentication needs to be done 
for each request, this may in fact be the best that can be done.

Paul

Received on Monday, 11 March 1996 18:32:36 UTC