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

Brian Smith wrote:
> 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.

Indeed. The updates of Trac and SVN seem to have affected the commit 
scripts (which, in this case, should have closed the ticket).

>> 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.

Yes (mod. ordering of events in time).

> 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).

Does this affect more headers than Set-Cookie?

> 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.

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

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.

BR, Julian

Received on Wednesday, 27 August 2008 20:35:54 UTC