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

dmk@research.bell-labs.com (Dave Kristol) wrote:
[ appended ]

	The commentURL points to a resource which can be requested by
a UA under a variety of circummstances, not just in conjunction with
an assessment of whether to accept a new (not previously accepted or
expired) cookie, or an assessment of whether to delete a previously
(e.g., tentatively) accepted cookie.  A link for that URL might have
been bookmarked, or added to some document.  The server thus must be
prepared to have Cookie headers in requests for those resources, and
should act on them as it would for other requests sent by UAs.  If
you impose restrictions for such URLs, you are creating complications,
not alleviating them.

	In those cases where the UA is sending the request in conjunction
with an assessment of whether to accept a new cookie or delete an existing
one, I still see no compelling reason to omit a Cookie header from the
request, if there are cookies which the UA would normally send to that
site.  I also think it is desireable to send at least the cookie for which
a comment is being requested, to ensure that at least one cookie is
included in the request (That's a MAY, not a MUST. :)  Such a cookie would
have the modern format for UAs which have adopted the modern IETF specs.
Consider, for example, the case for a host which does need to impose a port
restriction.  It's needs cannot be met by a blanket port restriction, as in
the current RFC.  The inclusion of a cookie with the modern format provides
assurance to the server that the request comes from a modern UA, and that a
document which is suitable for modern UAs can be returned.  Otherwise, the
server may elect to return a comment such as:

	WARNING: Your browser may have a historical implementation of
	cookie handling which inadequately protects your privacy and
	might result is transmissions of your cookies to inappropriate
	sites.  See IETF RFC??? <URL: ...> for more information.  A
	list of browsers with modern cookie support is available from
	<URL: ...>.  Such browsers will enable you to derived the full
	benefit of services offered by our site.

Of course, the WebMaster for the server might consider that particular
message impolite, or risks cache busting.  The point is that there are
reasons why it would be good to allow exchanges of cookies in conjunction
with the requests for commentURLs, and how they are handled is an
"implementation issue" dependent on the context in which the UA issues
the request.  All that's needed is a word of caution about getting caught
in a loop, and if you go too far beyond that at this time, it may turn out
that you're added a bug rather than alleviated a problem.

				Fote

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

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

Received on Wednesday, 23 July 1997 11:58:39 UTC