- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Thu, 01 Dec 2011 09:17:44 -0700
- To: Mark Nottingham <mnot@mnot.net>
- CC: ietf-http-wg@w3.org
On 12/01/2011 03:30 AM, Mark Nottingham wrote: > I think that's where we left it. > > This style of implementation often changes the stream; e.g., > > Connection: close > to > Connxxtion: close > > and similar. Likewise, implementations like those discussed could do: > > Content-Length: 100,100 > to > Content-Length: 100 <-- whitespace Absolutely, but the question paused by this thread remains: Are proxies _required_ to fix messages they forward? Or are they just required to interpret the messages they receive correctly? The HTTPbis specs do not give a clear answer, IMO, and should be adjusted one way or the other. I can propose specific wording changes if it helps but (a) I do not want to spend time on that if there is consensus that the current wording is good enough and (b) I need to know which way to polish (to require fixes or remove the implication that they are required). Thank you, Alex. > On 30/11/2011, at 2:58 AM, Alex Rousskov wrote: > >> On 11/29/2011 06:32 AM, Willy Tarreau wrote: >>> On Tue, Nov 29, 2011 at 11:55:56PM +1300, Adrien de Croy wrote: >>>> >>>> >>>> >>>> I can understand why someone would code some software that way, but I >>>> don't think it's correct to call that a proxy. At least it's not HTTP >>>> compliant. >>> >>> I 100% agree with you, that's why I stated that it was more of a gateway than >>> a proxy. >>> >>>> It could be argued that strategy of proxy operation is simply not valid. >>> >>> Agreed too! The term "proxy" is often used when connections are >>> re-established (TCP proxies) but I regularly repeat that in the HTTP >>> terminology that's not enough to be called a proxy. An HTTP proxy is a >>> well-defined entity that cannot simply be assumed by a TCP proxy. >> >> >> The scope of this thread question is not a TCP proxy. The core of the >> concern is a regular HTTP proxy. Some HTTP proxies prefer to forward >> message headers "as is" when possible rather than always recreating the >> forwarded message from internal metadata. Such proxies may still be >> compliant and interoperable if the specs are clear when it comes to >> forwarded message manipulation. >> >> The current requirements do not make it clear whether a compliant HTTP >> proxy may, for example, leave "Content-Length: 100,100" in the message >> it forwards while correctly interpreting that header as "Content-Length: >> 100". The uncertainty exists because the requirement uses the word >> "replace" but talks about message interpretation (which does _not_ >> require changing the forwarded message). >> >> Requirement: MUST replace the duplicated field-values with ... >> Scope or timing: prior to determining the message-body length. >> >> Possible solutions: >> >> 1) If the intent is to require that proxies fix messages they forward, >> then the requirement should be polished and split into two: >> >> MUST interpret the duplicated field-values as ... >> MUST replace such Content-Length header(s) with ... >> >> 2) If the intent is to require correct interpretation without mandating >> message fixes, then the requirement should be polished by changing >> "replace with" to "interpret as". >> >> >> What was the intent? Do we want to require all proxies to fix malformed >> Content-Length headers in forwarded messages? >> >> >> Thank you, >> >> Alex. >> > > -- > Mark Nottingham http://www.mnot.net/ > >
Received on Thursday, 1 December 2011 16:18:48 UTC