Re: NEW ISSUE: repeating non-list-type-headers

Jamie Lokier wrote:
> Julian Reschke wrote:
>> Now this seems to be kind of backwards, wouldn't it be *much* clearer if 
>> it said:
>>
>>    Multiple message-header fields with the same field-name MUST NOT be
>>    present in a message unless the entire field-value for that
>>    header field is defined as a comma-separated list [i.e., #(values)].
> 
> It would be clearer, but it would clash with reality.  All web servers
> and web clients use Set-Cookie, which is prohibited by that.

Well, it clashes with reality the same way the old text did :-)

That being said, we should treat that as separate issue. I believe Roy 
mentioned that problem before.

> I think it's important to acknowledge that Set-Cookie is still around,
> and all public web servers and clients must deal with it in practice
> (if they support cookies).

Agreed.

>> That being said, do we have a recommendation for recipients when that 
>> requirement is violated? I would assume that servers SHOULD return a 400 
>> (Bad Request), but what about clients?
> 
> An HTTP agent's implementation _ought_ to be able to parse the headers
> into a name->value dictionary, concatenating any multiple values for
> the same field-name with ", " between them, with the practical
> exception of Set-Cookie, for which a list must be kept separately.
> 
> Some servers and clients are implemented like that, and they are fine.
> 
> The module responsible for parsing headers generally doesn't have a
> list of the syntaxes of each header type, and such a list would be
> difficult to obtain because of application-specific headers which may
> be different for different resources on the same server.
> 
> Hence the open-endedness of the text you focused on in RFC 2616, I guess.

That's all true, but it doesn't answer the question of what a recipient 
should do with something like:

    Content-Type: text/html; charset=ISO-8859-1
    Content-Type: text/plain

(see <http://lists.w3.org/Archives/Public/public-html/2007Nov/0271.html>).

...or even worse, with conflicting Content-Length headers....

Best regards, Julian

Received on Tuesday, 20 November 2007 16:16:36 UTC