Re: #879: Should servers interpret Transfer-Encoding in 1.0 requests?

On 13/07/21 7:43 pm, Mark Nottingham wrote:
> <https://github.com/httpwg/http-core/issues/879>
> 
> Some security researchers have found what appears to be a situation where handling of Transfer-Encoding and Content-Length in a particular deployment can introduce a request smuggling vulnerability, even if the specification's requirements are followed closely.
> 
> See the issue for details. The heart of the question at this point is whether we can strengthen (to a SHOULD or MUST) or otherwise qualify this 'ought':
> 
>> If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length.  Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error.
> 
> Their research indicates that a number of servers don't reject such requests.
> 
> Could implementers take a look and weigh in (here or on the issue)?


There is allowance in the main spec for senders to deliver HTTP/1.0 on 
messages even if the sender supports a higher version if it believes the 
server is HTTP/1.0-only.


Squid has configurable strict and relaxed modes of message parse/validate.

The relaxed mode (default) accepts such messages as if HTTP/1.1 sender 
was trying to work around such buggy servers. Obeys the spec rules about 
T-E overriding C-L. Then goes right on and sends HTTP/1.1 version to the 
server anyway.
  *IF* the client was right about the servers bugs needing "HTTP/1.0" we 
are probably wrong to send the "HTTP/1.1". But I am not aware of any 
problems being reported about it, ever.

The strict mode should be responding with an 'invalid-request' error 
about framing issues spotted.


Amos

Received on Sunday, 18 July 2021 07:52:00 UTC