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

Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo

From: David W. Morris <dwm@xpasc.com>
Date: Tue, 22 Jul 1997 14:35:09 -0700 (PDT)
To: Dave Kristol <dmk@research.bell-labs.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970722140808.21389G-100000@shell1.aimnet.com>
 

On Tue, 22 Jul 1997, Dave Kristol wrote:

> Dave Morris and others have pretty consistently supported the inclusion
> of a CommentURL attribute in Set-Cookie2.  I was in the process of
> editing that capability in for the next draft when I ran into the
> following puzzle:  how to express the general idea that no cookies
> should be sent or received during the inspection process.
> 
> Here's an illustration of the problem.  I send a request to foo.com and
> get back a cookie that contains
> CommentURL="http://foo.com/cookie-policy.html".  I'm given the option
> to inspect that CommentURL, so I do so.  The HTML could potentially
> have images in it, even links to images on advertising networks.  It
> could also have links to other pages on foo.com.  If I follow those
> links (all while supposedly inspecting the cookie policy), I get deeper
> and deeper into the site.  All the while cookie handling should be
> disabled, right?  How does it get re-enabled?
> 
> Does this wording express it adequately?:
> 
> If the user agent allows the user to follow the [CommentURL] link [as
> part of a cookie inspection user interface], it should neither send nor
> accept a cookie until the user has completed the inspection.

I believe that wording is safe but perhaps too conservative. I think the
only ambiguous case is if the
UA provides access to the CommentURL while the user is being asked whether
or not to accept a cookie. Once a cookie has been stored and the user
is simply reviewing cookies already acquired I can't see any problem 
with treating the CommentURL normally. I also don't see any conflict
with sending or receiving already approved cookies with the CommentURL
request. With those arguments in mind, how about the alternative:
   A potentially confusing situation exists if a user agent's cookie
   inspection interface allows a user to follow a CommentURL link
   within a dialog which is prompting the user to decide if the cookie
   containing the CommentURL is acceptable AND following the CommentURL
   link results in receipt of a new, not previously approved cookie.
   The useragent MAY discard any cookie received in this context in order
   to avoid the complexities of interacting with the user regarding nested
   set-cookie requests.  Servers which depend on cookies MUST allow for
   the possibility that URLs used in their cookie's CommentURL value
   will be ignored by user agents.

While much longer, this version is more specific to the case of a cookie
received with the CommentURL response. It 'requires' the client to 
include appropriate cookies with the CommentURL request and allows the 
client designer to provide a nest inspection interface if desired. It 
also allows the client designer to safely avoid the issue by dropping
cookies received or to accept previously approved cookies.

On the otherhand, the IETF definition of 'should' allows the same design
choices under the compelling reason argument so I can live with Dave's
proposed wording.

Dave Morris
Received on Tuesday, 22 July 1997 14:40:36 EDT

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