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

Hi Amos,

On Tue, Nov 29, 2011 at 06:45:56PM +1300, Amos Jeffries wrote:
> On 29/11/2011 3:05 p.m., Dmitry Kurochkin wrote:
> >Hello.
> >
> >HTTPbis part 1 section 3.3 has the following requirements:
> >
> >   If more than one Transfer-Encoding header field is present in a
> >   message, the multiple field-values MUST be combined into one
> >   field-value, according to the algorithm defined in Section 3.2, before
> >   determining the message-body length.
> >
> >   If a message is received that has multiple Content-Length header
> >   fields (Section 8.2) with field-values consisting of the same decimal
> >   value, or a single Content-Length header field with a field value
> >   containing a list of identical decimal values (e.g., "Content-Length:
> >   42, 42"), indicating that duplicate Content-Length header fields have
> >   been generated or combined by an upstream message processor, then the
> >   recipient MUST either reject the message as invalid or replace the
> >   duplicated field-values with a single valid Content-Length field
> >   containing that decimal value prior to determining the message-body
> >   length.
> >
> >It is not clear whether proxies that do not reject the message MUST
> >replace the duplicated field-values in the forwarded message.  In other
> How is "MUST ... replace the duplicated field-values with a single valid 
> Content-Length field" unclear?
> >words, are non-transforming proxies required to either reject or fix the
> >message?
> Yes. "MUST either ... or ...."
> Depends on your philosophy IMO. If you want to be hardline and prefer 
> reject over header alterations its allowed.

I understand Dmitry's point. I think he's using a proxy which is more a
gateway in fact, which does very few things and just tries to stay in sync
with the stream and to avoid alterations as much as possible. That's what
is one in IPS, load balancers or any product which needs to read HTTP
without being intrusive. I've had the same experience with haproxy, where
HTTP was added as minimal processings on top of TCP before being improved
with time.

My personal rule of thumb on this is that if you don't touch anything, you
can't make things worse ; if you find that there is a real danger in what
you see, you should close ; if you find that what you read is not perfect
but should cause no risk (at worst just fail), then it's better not to
alter the stream.

In his situation, there is a difference between the interpretation of the
content-length and modifying it before forwarding it. If his product is
just forwarding the TCP stream and not producing the headers, he's not
violating the HTTP specs (otherwise routers would be too). However if he
detects something abnormal he can't understand, it would seem quite dangerous
to ignore it and let it pass.


Received on Tuesday, 29 November 2011 06:39:17 UTC