Dave Kristol wrote:
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?)
Versions since 2.0 should be able to handle any date format you
throw at it.
:lou