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

Jonathan Stark <stark@commerce.net> wrote:
>[...]
>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.

	Parsing error, indeed.  The server should not send any "new" cookies,
meaning none that are not included in the UA's Cookie: header, and the UA
should deal with the situation of a server doing so.  However, if you get
so heavy handed as to bar any cookie exchanges, that's like the blanket
port restriction in the current RFC, with it's side effect of blocking
all cookie sharing between http and https servers, including unencrypted
cookies from an http server going encrypted to an https server.  If you
make it that heavy handed, even UAs which do want to implement the IETF
specs are likely to respond with "Sorry, we're not going off the deep end
with you."

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Tuesday, 22 July 1997 17:38:05 UTC