Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo
Dave Kristol (dmk@research.bell-labs.com)
Tue, 22 Jul 97 15:51:29 EDT
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