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

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

Received on Wednesday, 23 July 1997 14:42:52 UTC