At 11:18 AM 6/20/2005, jean-frederic clere wrote: >>>Correct, I have a new additional patch that prevent multiples C-L headers. >> >>It isn't needed for reasons I pointed out on the dev list. >>Content-Encoding: x followed by Content-Encoding: y becomes >>Content-Encoding: x, y - this is rejected later in the process >>due to the non-numeric text ", ". > >But the patch stops the processing of the bad request earlier.
from RFC 2616 4.2 Message Headers 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. E.g. Accept[-*]: Allow: Cache-Control: Connection: Content-Encoding: Content-Language: Expect: If[-None]-Match: Pragma: Proxy-Authenticate: Range: (?the bytes=1#() target so I'm uncertain) TE: (literal TE, meaning acceptable response T-E choices) Trailer: Transfer-Encoding: Upgrade: Vary: Via: Warning: WWW-Authenticate: Every other header is equally guilty if we send multiples. Obviously some extension headers not defined in RFC2616 also follow some #() grammer. Cookies come to mind. Bill
