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: Jonathan Stark <stark@commerce.net>
Date: Tue, 22 Jul 1997 14:53:02 -0700 (PDT)
Message-Id: <199707222153.OAA21940@boa.commerce.net>
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3859

> >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 think that's absolutely correct.  It's the only way not to confuse
either a script on the server side, or the state on the UA side.

> 	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.

The reason for not sending or accepting cookies is that the whole
purpose of the CommentURL is to allow the user to evaluate the
pros and cons of accepting a cookie.  If you offer another cookie
while they're trying to decide if they should accept the first cookie,
now they potentially have to evaluate whether they want to accept the
second cookie, presumably before they can even look at the information
explaining the first cookie.  Obviously, this could be a very annoying 
endless loop to nowhere.

We also don't want to appear to be advertising to the Server that there's
an opportunity to change the state on this particular user while he
grabs the CommentURL.  Sorry for the wording here, but if the server
expects the client to accept the change on a cookie that IS already being
used, and the user agent doesn't accept the change because it's retrieving 
a CommentURL, the applications on the server side may become confused.

> 	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.

You can't put the responsibility for this on the server.  It must be
in the client.  At the very least, the client should ignore any "new"
cookies.  I think, however, it best to not accept any cookie actions
while getting the commentURL document.  Some scripts may not react 
well to having a cookie expire, and having another cookie that was 
issued in the same request not get set.  The "correct" action would be 
to feign ignorance of cookies and do nothing to the state of the UA 
until a decision is made on accepting or refusing the original cookie 
in question.  As stated in the original message, the UA should also
not send any cookie information when retrieving the CommentURL.

> 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
> sought.
> 				Fote

ouch... parse error line 3...  sorry... The reply to what?  To the request for
the CommentURL?  The UA just needs to know if it should or
should not accept a cookie that's been sent to it.  The CommentURL allows
the user to make an informed decision about whether they should or
should not accept the cookie.  The process of attaining this "decision
making information" should be "sacred"...  without cookies or sessions
or anything... it should be anonymous, as though the browser does not
have support for cookies, and it should not be something that will result
in any cookies being accepted, rejected, or changed in any way, except
for the one cookie that is in question, and the point of the whole process.

Received on Tuesday, 22 July 1997 14:59:55 UTC

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