RE: Set-Cookie vs list header parsing (i129)

Julian Reschke wrote:
> For now, I have submitted the change, and closed the issue 
> (see <http://tools.ietf.org/wg/httpbis/trac/changeset/310>).

The ticket is still open in the tracker.

> The new text now states:
> 
>        Note: the "Set-Cookie" header as implemented in practice (as
>        opposed to how it is specified in [RFC2109]) can occur multiple
>        times, but does not use the list syntax, and thus cannot be
>        combined into a single line.  (See Appendix A.2.3 of 
>        [Kri2001] for details.)  Also note that the Set-Cookie2 header
>        specified in [RFC2965] does not share this problem.

I am not against having this note but it doesn't address the real problem.
RFC 2616 required everybody to define header fields with syntax that is
compatible with the list syntax, but that requirement hasn't been followed.
In general, an intermediary cannot tell the difference between a header
field that is multi-valued using the list syntax, a header field that is
multi-valued but (illegally) using some other list syntax, and a header
field that is single-valued but erroneously repeated. If an intermediary
combines two single-valued header fields together then it could change the
meaning of the request/response if the combined value is also a legal value
for that field (see http://tools.ietf.org/wg/httpbis/trac/ticket/93).

Like Dan said, it is best to say an intermediary SHOULD NOT combine headers
fields in requests. Also, a client SHOULD NOT send requests with multiple
header fields with the same name, because many commonly used server gateways
(e.g. CGI and derivatives like Python's WSGI and Ruby's Rack) only allow a
single instance of each request header field. If the client provides more
than one header field with the same name, then the application server (for
these frameworks) will have to combine them. Some implementations don't do
this correctly (especially WSGI implementations).

- Brian

Received on Wednesday, 27 August 2008 20:15:37 UTC