- From: Paul Leach <paulle@microsoft.com>
- Date: Tue, 16 Apr 1996 16:02:02 -0700
- To: "'koen@win.tue.nl'" <koen@win.tue.nl>
- Cc: "'fielding@avron.ICS.UCI.EDU'" <fielding@avron.ICS.UCI.EDU>, "'http-caching@pa.dec.com'" <http-caching@pa.dec.com>, "'jg@w3.org'" <jg@w3.org>
I have strengthened my objection: I don't think it works for caches to generate their own variant-ids. Consider: 1. cache C assigns a variant-id V for entity E and passes it to a client 2. entity E is tossed out of the cache C 3. Client requests entity E, passing in V 4. Cache C passes the request to the origin server 5. V is meaningless to the origin server, because it didn't create it. Worse, it might duplicate one that it did assign, and cause incorrect results. >---------- >From: Paul Leach >Sent: Tuesday, April 16, 1996 1:31 PM >To: 'koen@win.tue.nl' >Cc: 'fielding@avron.ICS.UCI.EDU'; 'http-caching@pa.dec.com'; >'jg@w3.org' >Subject: RE: Variant-ID proposal > >I object to caches assigning variant-ids. If they're needed for >pre-emptive content negotiation by caches based on what is the >Alternates header, then the origin-server should generate variant-ids >for each alternate and return them in the alternates header. > >It'll be a lot simpler that way. > >>---------- >>From: koen@win.tue.nl[SMTP:koen@win.tue.nl] >>Sent: Tuesday, April 16, 1996 12:31 AM >>To: Paul Leach >>Cc: fielding@avron.ICS.UCI.EDU; koen@win.tue.nl; >>http-caching@pa.dec.com; jg@w3.org >>Subject: Re: Variant-ID proposal >> >>Paul Leach: >> [Koen Holtman:] >>>>If you have two orthogonal mechanisms, you can't have them share the >>>>same space in the Cval: header. >> >>>This sounds to me like you're confusing protocol mechanisms and >>>implementation mechanisms. There are two orthogonal protocol mechanisms >>>here, but in any server, I would imagine only one implementation >> ^^^^^^^^^^^^^ ^^^^^^^^ >>>mechanism, which would _indeed_ share the same variant-id scheme. Hence, >>>I don't agree that the design principle you invoke applies to this case. >> >>I think the response I just sent to Roy explains why this reasoning is >>wrong: there will _not_ be one implementation mechanism, placed in the >>origin server, assigning variant-ids for responses of a particular >>resource. Such mechanisms can also be present in all proxies in front >>of the origin server, because these will want to do preemptive >>negotiation on behalf of the origin server. >> >>If only the server assigned variant-ids, we could allow it to mix the >>data of the alternates-part and the variant-part into an opaque token >>in an undefined way. But this is not the case. >> >>>Paul >> >>Koen. >> >
Received on Tuesday, 16 April 1996 23:31:10 UTC