Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo

On Tue, 22 Jul 1997, Dave Kristol wrote:

> Recently there was discussion between Dave Morris and me about whether
> the request-host needed to be a FQHN, about changes to the definition
> of domain-match, and about the treatment of the Domain= attribute in
> Set-Cookie2.  The gist of the discussion was:  "Host names can be
> specified in any form acceptable to the base HTTP protocol. That may be
> an IP address, an incomplete host name string, or a FQHN string which
> is the prefe[r]red form."  I've done some more thinking about it and have
> the following observations.
> 
> 1) (Sect 2) Relax requirement that request-host be a FQHN.
> 
> Okay.  request-host could be any name string.
> 
> 2) (Sect 2) Change domain-match algorithm.
> 
> Okay.  A domain-matches B if the strings for A and B exactly match,
> whether they are IP addresses, partial name strings, or FQHNs.
> 
> 3) (Sect 4.3.2) Allow a Domain= value not to start with '.' and force a
> '.' in front of any such value.
> 
> No.  Suppose your local network has a host "com".  This transaction ensues:
> 
> 	C -> S
> 	GET /cgi-bin/foo HTTP/1.1
> 	Host: com
> 	[other stuff]
> 
> 	S -> C
> 	HTTP/1.1 200 OK
> 	Set-Cookie: foo=bar; Domain=com
> 	Set-Cookie2: Version="1"
> 
> The proposed rule would have two undesirable effects, because the domain for
> the cookie would become ".com":
> 
> 	a) You could not return cookie "foo" to the server you got it from,
> 	because "com" does not domain-match ".com".
> 
> 	b) Cookie "foo" would get sent to every server of the form "*.com".
> 
> 
> The effect of doing 1 and 2 (and not 3) above would be:
> 
> 1) You could use incomplete domain names (need not be FQHN) in Domain=.
> 2) The rule about the implicit value for Domain= would remain, namely that
> a cookie sent in a Set-Cookie[2] that had no Domain= attribute could only
> be returned to the server from which it came.
> 
> Question to Dave Morris:
> Would those changes meet your needs?
> 
Dave Kristol and I have had some extensive discussions over the details
and I believe we are in complete violent agreement now so let me
sumarize our discussion and my response to the above based on that 
summary.

Dave now agrees that my proposal to relax the handling of the domain=
attribute such that the user-agent may accept a value w/o a leading
dot but it must prepend a dot in that case before using the value.
All the other rules about embedded dots remain so the domain=com
example above would not apply.

The various requirements re. FQDN and FQHN are relaxed in favor of
the already existing rules about embedded dots which make the 
host names look like a FQHN. The bottom line is that a server
and/or client really can't tell if a three level name is a true FQHN
or an arbitrary sub-part such as x.y.z of x.y.z.foo.com since 
the number of TLDs is going to greatly expand and alternatives like
AlterNic make even the expanded TLDs moot for comparison purposes.

For practical purposes, for a user-agent to make a request of a non-local
server, it will have the FQHN of the server so the 'relaxed' but
previously unenforceable rules will not enable cookie sharing outside
of a local private network.

The current domain matching rules are: 

  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, x.y.com
      domain-matches .y.com but not y.com.)

And these would become:

  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 strings and their host name strings match
      exactly; or

    * A is a string and has the form NB, where N is a non-empty name
      string, B has the form .B', and B' is a string containing at least
      one (1) embedded dot. (So, x.y.com domain-matches .y.com but not
      y.com.)

So at this point my answer is yes, I'm completely satisfied with the 
result.

Thanks to all for your patience!

Dave Morris

Received on Wednesday, 23 July 1997 00:45:43 UTC