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

On Thu, 24 Jul 1997, Koen Holtman wrote:

> Dave Kristol:
> >
> [...]
> >Does this wording express it adequately?:
> >
> >If the user agent allows the user to follow the [CommentURL] link [as
> >part of a cookie inspection user interface], it should neither send nor
> >accept a cookie until the user has completed the inspection.
> I think the approach to solving this problem is wrong: the burden of
> ensuring that the commentURL mechanism does not lead to
> user-unfriendly or recursive situations should be on the server side.
> I propose something like this:
>  Servers SHOULD ensure that the user can visit the information pointed
>  to by the commentURL without causing the user agent to receive
>  additional Set-Cookie2 headers.  User agents SHOULD guard against the
>  entering of infinite loops due to the commentURL mechanism, and MAY do
>  this by disabling cookie processing when the commentURL is visited.

That would be needless complexity. Prior to this suggestion, the server
has had no special responsiblity other than to provide a URL which can
be retrieved from some server.  Secondly, the UA has many alternatives
for dealing with the possible looping issue including if its designer
so chooses doing nested interactions with the user, or flattening the
process and pending the nested cookie handling until the first cookie
is fully dealt with. Making a requirement on the server changes this
section from implementation advice into a protocol requirement.

The only appropriate solution falls to the UA's UI design. It is only
user unfriendly if the UI design makes it unfriendly.  And since UAs
would under this suggestion be expected to guard against the problem,
they might as well just take care of it.

Dave Morris

Received on Thursday, 24 July 1997 22:32:04 UTC