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

[Discussing language that would state under what circumstances a UA,
examining a page fetched via CommentURL, would accept a cookie...]

Scott Lawrence (responding to Foteos Macrides):
> >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.
> 

Foteos Macrides:
>         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."

The folks arguing *for* CommentURL say it's a valuable feature and (I
think they would claim) easy to implement.  I agree that, at the
bits-on-the-wire protocol level, it's simple to specify, but I've always
been skeptical about the UA implications.  I think Foteos's wording for
how a UA should handle a cookie that it receives while examining a
CommentURL page (not reproduced here) help to make my point.  I think
they're complex.

Some of the disagreement results from differing visions of when/how a
user could inspect a cookie.  (And we must allow for that flexibility.) 
I imagined that the inspection would take place at the point where a
cookie arrived, subsequent to a user's clicking on a link, and before
some or all of the content has been received.  In that circumstance, if
the UA offers the user the opportunity to follow the CommentURL link for
the cookie, I think it's inappropriate for the UA to send a cookie to
the very server whose cookie policy the user is (presumably) about to
examine, or to accept cookies from that server or others.

On the other hand, if the cookie inspection mechanism is "off-line", in
the sense that it functions when the UA is otherwise quiescent (no page
retrieval taking place), then different rules may apply.  The
interrogation of the CommentURL could be treated similarly to retrieval
of any other resource.

I think a UA could (perhaps *should*) provide both mechanisms.  The
question is (assuming you agree with the two paragraphs above) how to
word the spec. to restrict the first case and not the second.  Dave
Morris proposed:

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

That's not bad.  In his related commentary Dave (Morris) said that
previously accepted cookies could be returned with CommentURL.  I don't
think I agree, but in any case I don't see that addressed in these words
(though it's not ruled out, either). 

Here's my rewording of Dave Morris's words:

A potentially confusing situation exists if this sequence occurs:
	- the user agent receives a cookie that contains a CommentURL
attribute;
	- the user agent's cookie inspection interface presents a dialog that
allows the user to follow the CommentURL link; and,
	- when the user follows the CommentURL link, the origin server (or
another server, via other links in the returned content) returns another
cookie.

[My addition:]  The user agent should not send any cookies in this
context.  The user agent may discard any cookie received in this context
that the user has not, through some user agent mechanism, deemed
acceptable.

[I left out the remark about allowing for ignored cookies, because
that's always true.]

Dave Kristol

Received on Wednesday, 23 July 1997 08:47:27 UTC