- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Tue, 22 Jul 97 15:51:29 EDT
- To: dwm@aimnet.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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
Received on Tuesday, 22 July 1997 12:56:48 UTC