W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: Proposal: Vary on Cookies

From: Richard Vermillion <rvermillion@cyberdialogue.com>
Date: Thu, 12 Jun 1997 20:49:23 -0400
Message-Id: <199706130049.AA104372963@hplb.hpl.hp.com>
To: "David W. Morris" <dwm@xpasc.com>
Cc: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3528

Thanks for your response.  I did take a look at the Transparent
Content Negotiation draft, but it didn't seem to address my problem
directly.  Correct me if I'm wrong, but draft-ietf-http-negotiation-02.txt
seems to discuss only the normal usage of Vary, i.e. using it with actual
complete headers.  In Section 10.6.1, it discusses contructing "elaborate
Vary headers", but these are constructed using only the Negotiate, Accept,
Accept-Language, and Accept-Feature headers, e.g.:

    Vary: negotiate, accept, accept-language

I see your point in that I am basically talking about doing content
negotiation with a remote variant selection algorithm which happens to
take into account cookie values.  The unfortunate thing is that all of
the cookie values are lumped into one header, "Cookie".  So, I'd like
to be able to tell compliant proxy-caches that I only "selected" on
a part of that cookie header.


Richard Vermillion                                         212 255 6655 x106
Cyber Dialogue                                 rvermillion@cyberdialogue.com

> From: "David W. Morris" <dwm@xpasc.com>
> To: Richard Vermillion <rvermillion@cyberdialogue.com> 
> CC: HTTP Working Group <http-wg@cuckoo.hpl.hp.com> 
> Subject: Re: Proposal: Vary on Cookies 
> Date: Thu, 12 Jun 1997 16:26:06 -0700 (PDT)
>Why don't you take a look at the Transparent Content Negotiation draft
>suite? I think most/all of what you are concerned with could be nicely
>accomplished via TCN and feature registration.
>If not, perhaps there is a smooth way to integrate cookie values into TCN.
>On Thu, 12 Jun 1997, Richard Vermillion wrote:
>> I've been a lurker on the HTTP-WG list for about a year now, paying
>> particular attention to the HTTP State Management threads.  I know this
>> might be a bad time to propose an addition to the spec (considering the
>> turmoil it seems to be in now, and that it seems to have fled to a 
>> sub-group), but I believe this functionality might be worth adding.
>> If this functionality already exists, please let me (and the other
>> cache-conscious dynamic-content implementers out there) know.  If there
>> is a better forum for proposing this, let me know also.
>> Often times, cookies are used to describe a characteristic of a visitor. 
>> These characteristics might be:
>>   o Preferences the visitor has set earlier (e.g. Frames=no or
>>     LotsOfImages=yes or Bgcolor=blue)
>>   o Flags to mark the visitor (e.g. AnsweredQnr=yes; this person has
>>     already filled out our questionnaire so don't ask again)
>>   o The market segment of the visitor (and this will grow in
>>     importance as online commerce ramps up) (e.g. BuyACar=3; they're
>>     pretty likely to buy a car)
>[.... remainder, snipped ... the above should refresh context ]
>Check out 
>   draft-ietf-http-rvsa-v10-0*.txt
>   draft-ietf-http-negotiation-0*.txt
>   draft-ietf-http-feature-reg-0*.txt
>Dave Morris  
Received on Thursday, 12 June 1997 17:51:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC