- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Fri, 02 Dec 2011 14:12:14 -0700
- 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 UTC