httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: 2.1.5 available for testing
Date Mon, 20 Jun 2005 17:02:23 GMT
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
  
   


Mime
View raw message