- From: Paul Leach <paulle@microsoft.com>
- Date: Mon, 11 Mar 96 11:07:01 PST
- To: fielding@avron.ICS.UCI.EDU
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
---------- ] From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU> ] Date: Sunday, March 10, 1996 8:51PM ] ] 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? ] ] Combined with my other suggestion (to make validators a change indicator), ] we could considerably reduce the number of additional header fields ] sent on these requests and responses. ] ] In other words, this is the same as my IF-ID/Unless-ID/Content-ID ] proposal but without the "world uniqueness" and usage of the <mailbox> ] format. Good point. The one thing that I think still differs is that lost is the ability for the cache to know that several things with the same URI are variants of one another, as opposed to just a single instance that has changed over time. With IF-ID/Unless-ID/Content-ID: Client Server GET /foo.txt HTTP/1.1 HTTP/1.0 200 OK Content-ID: "asdasfa" GET /foo.txt HTTP/1.1 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? With Variant-ID, it would be clear: Client Server GET /foo.txt HTTP/1.1 HTTP/1.0 200 OK Cache-Validator: "asdasfa" Variant-ID: 1 GET /foo.txt HTTP/1.1 HTTP/1.0 200 OK Cache-Validator: "xxxx" Variant-ID: 2 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 thought that Content-ID was aligned with some other MIME standard header, though, so this syntax may not be acceptable for that reason -- but any other spelling would be OK. Paul
Received on Monday, 11 March 1996 11:06:07 UTC