Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo
Dave Kristol (dmk@research.bell-labs.com)
Wed, 23 Jul 97 17:38:34 EDT
Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
> 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.
Not really. The server has to be prepared not to receive the cookie
back in any event. Also, the complications I was trying to alleviate
were on the UA side, not the server side.
>
> 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
Think again about that. Suppose site a.com sent cookie X=1 previously.
I go to a.com again, send cookie X=1, get a new cookie, X=2, and pop up
a cookie inspection dialog. CommentURL directs me to a URL on a.com.
I certainly don't want to send X=2: that's the cookie I just got, and
I'm trying to decide whether to accept it. But I just sent X=1. Does
it help to send it again in this context?
> a comment is being requested, to ensure that at least one cookie is
On the contrary. I haven't decided whether I want to accept that cookie.
Why should I send it back before accepting it?
> 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.
I think the server will be able to recognize good cookies whenever it
receives them. I don't see the relevance of receiving a cookie during
the inspection process. For example, a user might decide never to
inspect cookies.
>
> 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.
I remain unpersuaded. It would help me if you would comment on my
proposed words and/or, especially, if you would propose words you
consider suitable in their stead.
Dave Kristol