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

Julian Reschke wrote:
> Does this affect more headers than Set-Cookie?

Dan pointed out that it also affects WWW-Authenticate. Dan's point (which I
agree with) is that since we've already found two specific header fields
where combining is problematic, it is safer to just recommend that
implementors avoid the problem generally. Attempting to solve the problem by
enumerating the header fields that are known to be problematic is too
brittle.

> > 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).
> 
> I'm not totally sure what your suggestion is.

Proxies SHOULD NOT combine header fields. Clients SHOULD combine header
fields in requests so that  there is at most one instance of each header
field in the request. 

> I don't think that changing things just because some 
> implementations get them wrong is on our agenda.

AFAICT, this is the primary motivation for HTTPbis--to clarify parts of the
specification where there are known interoperability problems. A
proxy/client that follows the two recommendations above will interoperate
correctly with more implementations than one that doesn't follow those
recommendations.

> The case for Set-Cookie is different, because any 
> implementation that does support (old-style) cookies must be 
> aware of the difference wrt RFC2616's rules.

Again, WWW-Authenticate has the same problem, and other header fields
probably do to.

Regards,
Brian

Received on Thursday, 28 August 2008 00:18:32 UTC