Re: new cookie draft

Yaron Goland <> writes:

>I would suggest changing the domain specification to allow for the
>inclusion of port number. So a domain could look like "".
>Now if a site is concerned about someone taking over a port, they can
>specify that only the identified port may be used. If they control the
>entire server and have no worries, they may then leave the port number

I agree with Yaron - there are many environments where two ports on the
same host are under wildly different and often legitimate ownership, and
allowing the server to specify a port (but not requiring it to do so)
would help in those environments.  Claims that it's difficult to keep
"rogue" servers up are specious, depending as they do on suppositions of
local system management and reliability.  I can point to large mainframe
hosts that aren't "rebooted" for many months at a time, making the
lifetime of servers running on high-numbered ports rather long.

That said, the requirement that the DOMAIN attribute specify a
domain-suffix (i.e. "" is legal, "" is not) limits the
exposure to sites where an entire subdomain is involved.  I'm willing to
accept the argument that mutually-hostile servers spread across a group
of hosts and nonetheless using DOMAIN is a vanishingly small population.

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

   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?

   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?

   3) Section 2 "TERMINOLOGY" says that:

         Host names can be specified either as an IP address or a FQHN
         string.  Sometimes we compare one host name with another.  Host
         A's name domain-matches host B's if

            * both host names are IP addresses and their host name
              strings match exactly;  or

            * both host names are FQDN strings and their host name
              strings match exactly;  or

            * A is a FQDN string and has the form NB, where N is a
              non-empty name string, B has the form .B', and B' is a
              FQDN string.  (So, domain-matches but not

      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

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Friday, 21 March 1997 08:26:31 UTC