- From: David W. Morris <dwm@xpasc.com>
- Date: Thu, 24 Jul 1997 22:28:11 -0700 (PDT)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: Dave Kristol <dmk@research.bell-labs.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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