RE: new cookie draft

I admit that port is a pit and I don't ever expect anyone to specify a
port. There are legitimate cases where one would want a cookie to go to
multiple ports. So rather than putting a blanket restriction I proposed
that we allow the server to decide what behavior they would like. We can
define an attribute "PORT", with no argument. If it is included in a
cookie then the cookie may only be returned on the port it was received
on, this requirement applies to all domains. This recreates the current
restriction in the spec. If the server is not concerned about the issue
of ports, then it leaves the attribute off and the client is free to
return the cookie on any port in a legal domain.
		Yaron

> -----Original Message-----
> From:	Dave Kristol [SMTP:dmk@bell-labs.com]
> Sent:	Friday, March 21, 1997 8:56 AM
> To:	Ross Patterson
> Cc:	http-wg@cuckoo.hpl.hp.com
> Subject:	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 15:56:15 UTC