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: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 22 Jul 1997 17:21:31 -0500 (EST)
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3855
dmk@research.bell-labs.com (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 don't see why you want to exclude sending of cookies when
a UA is acting on the commentURL, nor why you are conceptualizing it
as only for a policy statement.  That's possible, but the PEP or
PEP-like extension is a better way to assess a site's "policy".  One
of the main reasons for wanting cookie support in UAs is that it's a
simple, "here now" way to maintain user preferences across documents
at a site, and is complementary to the TCN/features mechanisms.  The
hope is that the reply will include a statement about the purpose of
that particular cookie, and "preference cookies" should still be able
to affect how the reply is structured.

	You simply want to guard against the server trying to set new
cookies via the reply to the commentURL request, and there too, you
need not exclude things like it expiring or modifying old cookies
which the user accepted.  How about something like this:

	If the user agent allows the user to follow the CommentURL
	link as part of a cookie inspection user interface, the server
	should not include any new cookies in the reply, and the UA
	should allow the use to inspect the body of the reply before
	acting on any other commentURL links.

If this is a "first contact", or is consequent to the user having
enabled formerly disabled cookie support, that degrades to the
reply having no more than the cookie about which a comment is being


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Tuesday, 22 July 1997 14:27:26 UTC

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