Re: new cookie draft

Ross Patterson wrote:
> 
> Yaron Goland <yarong@microsoft.com> writes:
> 
> [about ports...]

There seem to be two contradictory threads going on here.  On the one hand,
some folks want to be able to specify the port, to restrict where cookies
go.  On the other, folks want it to be possible to send the same cookie to
multiple ports on the same server.  And we have to remember the port 80
(http) vs. port 443 (https) problem, of sending a cookie in both a secure
and an insecure connection.

Another factor is that the same cookie can be sent to multiple domain
names.  Is the port transitive?

I oppose the idea of changing the Domain= syntax, for compatibility
reasons.  I can support a Port= addition to Set-Cookie2.  I had thought of
such before, and the port restriction I added was an attempt to accomplish
the restriction implicitly.

I would welcome a *complete* proposal for port handling that addresses the
concerns above, and that deals with what the correct behavior should be if
Port= is omitted from Set-Cookie2.

> [...]

> I've been avoiding commenting on the new draft, since I thought RFC 2109
> was good enough, but since I'm writing now, I have to make a few other
> points:
> 
>    1) "SetCookie2" is a lousy name for the function we're discussing.
>       "SetSessionState" or something similar would be much better than a
>       number-suffixed oddity.  If we MUST use the C-word, perhaps
>       "CreateCookie" or "DefineCookie" would do the job?

[Deep breath.  History, dating back to late 1995!]

In the beginning, those of us in the state management sub-group set out to
agree on a mechanism.  As a practical matter, with Netscape's cookies
already deployed, it made sense to standardize them, tightening up the spec
where we saw holes.  The idea was to have something fully compatible with
Netscape's cookies and most existing uses.  We planned to use Cookie and
Set-Cookie for the obvious reasons.

Recently we became aware of forward compatibility problems with MSIE.  My
attempt to address it has been to add another header which can eventually
subsume Set-Cookie.  Meanwhile (and the new I-D gives the rules), pieces of
Set-Cookie and Set-Cookie2 (the new header) get combined to form a complete
Set-Cookie2 header.  The goal has been to let V0 cookie clients continue to
work, V1 cookie clients begin to work, and both V0 and V1 servers can talk
to either flavor client.  Set-Cookie2 was chosen as an obvious relation to
Set-Cookie.  Why muck with it?  (I never liked Cookie or Set-Cookie, but
the exist, they work, and they won't go away.)
> 
>    2) If the resulting request header was "SessionState" instead of
>       "Cookie", wouldn't all the odd syntax that derives from
>       Cookie-compatability be resolvable?  I understand that this looks
>       like a large change, and is likely to raise someone's ire, but
>       changing from "SetCookie" to "SetCookie2" has already introduced a
>       sufficiently large incompatability that existing browers will
>       require code changes to support the new mechanism.  If code
>       changes are required, shouldn't we take the opportunity to resolve
>       things like the EXPIRES syntax?

If my paragraphs above haven't answered this, read the I-D (again).  We are
trying to introduce the new stuff compatibly.  Yes, it would be nice to do
something from scratch to "get it right", but it's a bit late for that.
The I-D addresses Expires in the transitional phase.  Note that there is no
Expires in Set-Cookie2 -- it's replaced by Max-Age.

> 
>    3) Section 2 "TERMINOLOGY" says that:
> 
> [definition of domain-match]
> 
>       This implies, especially to those who've never read the DNS RFCs,
>       that FQDN strings are case-sensitive.  Since domain names are not,
>       neither should they be.  I've had enough trouble convincing newbie
>       RFC-readers that this is the case elsewhere in HTTP that I'd like
>       to see it explicitly stated here.  Unless of course I'm completely
>       wrong.

You're right, FQDN's are case-INsensitive.  That's a note worth making.

Dave Kristol

Received on Friday, 21 March 1997 09:02:07 UTC