W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: clarify some MUST requirements in HTTPbis part 1 section 3.3

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Fri, 02 Dec 2011 14:12:14 -0700
Message-ID: <4ED93F2E.2030303@measurement-factory.com>
To: Willy Tarreau <w@1wt.eu>
CC: ietf-http-wg@w3.org
On 12/02/2011 01:39 PM, Willy Tarreau wrote:
> On Fri, Dec 02, 2011 at 10:21:42AM -0700, Alex Rousskov wrote:
>> If we state that, an HTTP proxy would have to make a choice when dealing
>> with a "broken" incoming message:
>>
>>   1) reject the malformed message
>>   2) forward a "fixed" message
>>   3) forward raw bytes, becoming a TCP tunnel
>>
>> Currently, many interpret HTTP specs as if there is another option:
>>
>>   4) forward the malformed message "as is"
>>      while interpreting it correctly internally.
> 
> Actually, it's even more common to see this :
> 
>     5) ignore 90% of headers you don't care about and for which you
>        don't know how to determine the validity, and apply 4) when
>        you care about the header.

Actually, RFC 2616 does define what a valid header is. Any header not
explicitly defined in that RFC still has to obey the rules for extension
headers. The proxy does not have to follow any other rules to stay
compliant.


> I don't see how we can impose 2) for the 90% headers that a proxy
> does not understand and just ignores.

Per my proposed wording, those headers do not need fixing: Any extension
header can be forwarded "as is" while staying compliant. There are some
nuances related to handling of multiple extension headers with same
names, but the same "as is" rule works for those as well.

If some specification defines an extension HTTP header that requires
special forwarding beyond RFC 2616 rules, that specification itself is
broken.


Thank you,

Alex.
Received on Friday, 2 December 2011 21:13:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT