Processing HTTP Headers violates RFC 2616 - same header-name with multiple fields and values not normalized

[hakre]

Quote:

 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. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

Summary:

• Multiple message-header fields with the same field-name MAY be present
  
• It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair
  

Currently the code is creating an array instead of a comma separated list.

[hakre]

Related: #9395

[dd32]

Can you post a reference for where the quote comes from?

Moving to Future Release pending patch.

[nacin]

Replying to dd32:

Can you post a reference for where the quote comes from?

RFC 2616, 4.2 (Message Headers)

[hakre]

Concating values as List; response header overwrite protection; diverse formattings

[hakre]

A first patch. There is another issue regarding the response status code and message by injecting header not containing any colons. That is somehow already prevented by the "redirection" handling (which will only return the last status field and/or the injected one as I just see, need to update the patch).

I'll update the current patch to remove my handling of that again.

Additionally there is another issue with tolerant status line parsing we do not cover:

Clients SHOULD be tolerant in parsing the Status-Line [...]. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.

Source: 19.3 Tolerant Applications / RFC 2616

We just do an explode on a single space.

[hakre]

Updated: Concating values as List; diverse formattings

[hakre]

Updated: Concating values as List; Better Status Line parsing; diverse formattings

[hakre]

Updated the patch according to my previous notes. Un-needed check for setting the status line has been removed again and the better status line parsing has been implemented according RFC instead.

I gave it a testrun on my testbed and it looks good from my side. I also tested the preg_split code on example data.

[hakre]

A little fix while in that file.

[dd32]

Will handle this in 3.1

[dd32]

After reading the spec closer, I see no need to change anything here.

Specifically, the RFC quoted is specifying that the fields MAY be combined into a comma separated list(and that servers MUST present multiple headers in a form in which combining to a comma separated list will retain the original meaning), It is not dictating how a client must present the data given to a client (Excluding proxies, who must present the headers in the order given to them, and must not combine them, so as to preserve the meaning behind the message)

Note, That this is different from unfolding where a header is split over multiple lines, and must be re-combined before presenting the field to clients.

[hakre]

Replying to dd32:

Note, That this is different from unfolding where a header is split over multiple lines, and must be re-combined before presenting the field to clients.

That has been already addressed in an earlier ticket and fixed: Related: #9395, [11351]

[hakre]

Replying to dd32:

After reading the spec closer, I see no need to change anything here.

Specifically, the RFC quoted is specifying that the fields MAY be combined into a comma separated list(and that servers MUST present multiple headers in a form in which combining to a comma separated list will retain the original meaning), It is not dictating how a client must present the data given to a client (Excluding proxies, who must present the headers in the order given to them, and must not combine them, so as to preserve the meaning behind the message)

I see and I can follow that argumentation. What has been represented as a comma separated list within headers is then represented as an array list in our PHP. I'm fine with that approach, I think that's correct after re-reading.

However that does as well mean that multiple header-fields with the same header-name are only correct, if the specification allows a list.

Regardless of that fact, I'm against being too strict here and compare against a list (for the moment) which header-names have such a property (list values) specified or not.

Instead I suggest for those headers that provide multiple header-values to check those if they already contain commas per one array entry and normalize all array entries to values w/o commas so the values are normalized.

[hakre]

process multiple headers the same as a comma sperated list of values and handle such a list as an array in PHP

[hakre]

And there was that minor patch left which is not in scope, but well, too less to open a ticket on it's own I suppose.

[hakre]

13513.minor.patch

[dd32]

no, Headers should be given as the server has presented it. If it offers a comma separated list, thats what should be passed back to the client.

As for the "minor patch", I prefer the more readable current form (Which is used in all the transports)

Closing as invalid due to not needing to implement it. (Please don't re-open this for the purpose of discussing the minor patch, as the purpose of the ticket is invalid anyway)

[hakre]

Note: 13513.3.patch has wrong order. First should not added behind next, but before.