Errata to RFC 2965, HTTP State Management

Issues

1. Can there be more than one Cookie header in a request?
2. Can multiple Cookie headers be combined?
3. Does path-match ordering apply both to multiple Cookie headers and to multiple cookies in one Cookie header?
4. When mixed V0/V1 cookies are valid, what should be sent to a server?
5. Should V0 cookies be sent to a V1 server?
6. Resolve references to "a Cookie header" vs. Cookie headers in general.
7. RFC 2965 is inconsistent about where quoted strings are permitted.
8. Make clear that "have the same value" for Cookie attributes means char-for-char.
9. Resolve ambiguity for "effective host name"
10. Syntax for $Port
11. Cite quoted-string
12. There's a typo in RFC2965, 3.2.2 (description of the attribute "Secure").
13. Should a client send $Domain with the implicit dot that gets prefixed to Domain?

Disposition:

We conclude that multiple Cookie headers may be present in a request. RFC 2965 has no specific words forbidding multiple Cookie headers, and the wording at least suggests the possibility of multiple headers.

If there can be more than one Cookie header in a request, can they be combined ("folded")?

Disposition: If so, then the syntax for Cookie needs to be changed.

Note: RFC 2616 (HTTP/1.1) says:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.

In other words, multiple headers are allowed if and only if they can be combined.

Disposition:

Suppose a user agent sends a request to a.example.com. Suppose, moreover, that the user agent has received Netscape ("V0") and/or RFC 2965 ("V1") cookies that have Domain=".example.com" from other example.com servers (but not a.example.com). What cookie(s), and in what form, should the user agent send to a.example.com? The problem is, we don't know whether or what kind of cookies a.example.com can handle.

Disposition:

Similar to the previous item. Suppose the user agent knows that server a.example.com accepts V1 cookies. Further suppose that the user agent has received V0 cookies (and only V0 cookies) from b.example.com. Should the user agent send the V0 cookies to a.example.com? If so, in what form?

Disposition:

Disposition:

RFC 2965 is inconsistent about where quoted strings are permitted. For example,

    set-cookie-av = "Version" "=" 1*DIGIT

Disposition:

Disposition:

There's a problem with the definition of "effective host name" (Arne Thomassen). If the host name comprises a numeric string with no dots, e.g. 42, which according to SUSv3 (Simplified Unix Standard) denotes an IP address, RFC 2965 still says the effective host name should be 42.local.

Disposition:

In the syntax line

    port = "$Port" [ "=" <"> value <"> ]

Disposition:

<quoted-string> is mentioned in RFC 2965 without a citation.

Disposition: Add citation to RFC 2616.

Disposition:

    s/confidentially and authenticity/confidentiality and authenticity/

See the thread that begins at http://lists.bell-labs.com/pipermail/http-state/2003q2/000251.html. The issue is that RFC 2965 directs the client to add a dot as a prefix to a cookie's Domain attribute if none is present. When the client returns the cookie to the server, should the value for $Domain that it sends contain the dot or not?

Disposition: Change the wording of Sect. 3.3.2 to be even more explicit that the client should send back to the server exactly what it got from the server:

The value for the domain attribute MUST be the value from the Domain attribute, if one was present, of the corresponding Set-Cookie2 response header; the value of the Domain attribute used SHOULD NOT include any initial dot added during client processing.