- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Thu, 13 Feb 97 16:04:30 EST
- To: koen@win.tue.nl
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, www-talk@www10.w3.org
> Two small comments on the errata: > > 1. The section `Compatibility with MS's implementation' states the problem, > but no solution. I'd prefer it if you append something like > > Therefore, servers should be careful in sending complex cookies that use > this specification to legacy HTTP/1.0 user agents. If an unknown HTTP/1.0 > user agent is encountered, a server can determine its compatibility with > this specification by first returning a response which sets a simple > non-persistent cookie, and then examining the cookie header of any > subsequent request. Okay, but.... Because the cookie spec. is separable from HTTP/1.1, and because it will become a standard after HTTP/1.1, there's no assurance that even HTTP/1.1 user agents will follow this spec. So it might be wise to avoid reference to HTTP/1.0. Also, what exactly do you mean by "unknown HTTP/1.0 user agent"? > > > 2. Benjamin Franz noted an ambiguity which could be interpreted in a > perverse way. In the following part of section 4.3.5: > > When it makes an unverifiable transaction, a user agent must enable a > session only if a cookie with a domain attribute D was sent or received > ^^^^^^^^ > in its origin transaction, such that the host name in the Request-URI of > the unverifiable transaction domain-matches D. > > `received' really means `recieved and not rejected'. So it is better to > replace `recieved' by `accepted'. Okay. It's actually better *not* to replace "received" with "recieved", and I will replace "received" with "accepted". :-) Dave Kristol
Received on Thursday, 13 February 1997 13:13:51 UTC