Comment by jsnell

> Content-Length+Transfer-Encoding should be bad request.

Maybe it should be, but it isn't. In fact, all revisions of the HTTP/1.1 RFC have made it clear that if both headers are present, the receiver must treat it as the Content-Length header not being present. Not as an error.

RFC 2616 "If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored."

RFC 7230 "If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length"

RFC 9112 "... Transfer-Encoding is defined as overriding Content-Length, as opposed to them being mutually incompatible."

> RFC is also not respected: "Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a"

That's a spec mistake in the original RFC, corrected in later revisions. It would be an absurd requirement: if the input is chunked, the output must be chunked as well. If the sender is sending gzip and the receiver accepts it, what is gained from the proxy decompressing the stream only to immediately compress it?

> Content-Lenght: \r\n7 is also a bad request.

... I mean, yes, it would be a bad request. But the example in the article is "Content-Lenght: \r\n 7" which isn't invalid. It's a feature defined in RFC 2616 as folding. It was a bad idea and deprecated in later revisions, but that just means that a client should not send it. A server or proxy can either reject the message or undo the folding, they're just not allowed to pass them through unmodified.