Re: new prospective cookie draft

Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
  > [...]
  > 	(1) In section 10.3 concerning compatibility with MicroSoft's
  > implementation, the wording implies that this is a "proper" Version
  > 1 Set-Cookie header:
  > 
  > Set-cookie: xx="1=2&3-4";
  >     Comment="blah";
  >     Version=1; Max-Age=15552000; Path=/;
  >     Expires=Sun, 27 Apr 1997 01:16:23 GMT
  > 
  > which MicroSoft's parser mishandles by sending:
  > 
  >     Cookie: Max-Age=15552000
  > 
  > instead of the "correct"
  > 
  >     Cookie: xx="1=2&3-4"
  > 
  > 
  > 	"Expires" is not one of the attribute names for Version 1
  > cookies.  Thus, isn't it a valid cookie name, and isn't it's presence
  > in a Set-cookie header that claims to be Version 1 but expects it to
  > be handled as a Version 0 Expires attribute invalid?  Also, skipping
  > that Expires ambiguity, isn't this what's "correct":

The sub-group originally thought it would be possible to send a single
Set-Cookie that would work with V0 and V1 cookies.  V0-capable browsers
wouldn't know what to do with the new stuff and would just pay
attention to the new.  V1-capable browsers would pay attention only to
what they understood and ignore the rest.  So the example Set-Cookie,
containing both Max-Age and Expires, could serve both.  Unfortunately,
MSIE can't handle this example.

(N.B.  I don't believe Netscape would handle the example Expires date.
Their spec said Wdy, DD-Mon-YY HH:MM:SS GMT.  Lou?  Ari?  Care to
comment?)
  > 
  > 
  >     Cookie: $Version=1; xx="1=2&3-4"; $Path=/; $Domain=foo.blah.dom

We could have been clearer.  "Correct" meant with respect to the older
specification, since we're talking about MSIE implementations that
pre-date state-mgmt-05.  Maybe we should say "expected" rather than
"correct".
  >     
  > 
  > 	(2) Re Section 10.2 concerning compatibility with Netscape's
  > original cookie implementation (Version 0), when initially implementing
  > the draft for Lynx v2.7, we interpreted it to be saying that in the
  > absence of a version parameter, the $Version= should not be prepended,
  > but the ; $Path=  and  ; $Domain=  still should.  That didn't work out

I think the spec. is a bit ambiguous here, since the words in 4.3.1
about Version could be read to mean "Behave in all respects like
Netscape's original behavior" if Version is absent from Set-Cookie.
However, looking through archived mail on our (private) sub-group
mailing list, I believe we intended for implementations that understood
V1 cookies to use them exclusively.

Can anyone else in the subgroup comment?

  > at all.  For example, if you try that with the www.research.digital.com
  > test service, it treats everything following the testcookie= as the
  > value (i.e., doesn't trim on the semi-colon), and reports a bad
  > value.  Looks like CyberDog initially implemented it that way and
  > similarly got false errors from that service.  I realize one could
  > say, "We'll, people should fix their parsers.", but in the real world
  > we didn't find a single case of proper parsing for Version 0 cookies,
  > and ended up dropping the use of $Path and $Domain unless the Set-Cookie
  > header includes a version=[ >= 1 ].  You might want to take that field
  > experience into account, or perhaps we misinterpreted the recommendation.

We might have to change the specification to be explicit that user
agents return V0 cookies to V0 servers and V1 cookies to V1 servers.

Dave Kristol

Received on Tuesday, 18 February 1997 14:10:47 UTC