[PATCH] Fix for the HT on request headers problem (#1752)

[Maxim Dounin]

Hello!

On Mon, Jan 20, 2020 at 05:29:25PM +0200, mstavrev at gmail.com wrote:

> # HG changeset patch
> # User Marin Stavrev
> # Date 1579526641 -7200
> #      Mon Jan 20 15:24:01 2020 +0200
> # Node ID bf238762fdaf03383c2f3c3718c401e6141e3935
> # Parent  6439ef81e37dfccfc3a8c57fed278bf56014ef39
> Fix for the HT on request headers problem (#1752)
> 
> When client send HTTP request with a header of Content-Length that starts with
> horizontal tab character (HT=0x09), Nginx responds with HTTP 400 Bad Request.
> According to HTTP RFC2616 section 4.2, "... The field value MAY be preceded by
> any amount of LWS, though a single SP is preferred.". The difinition of LWS is:
> 
>   LWS = [CRLF] 1*( SP | HT )
> 
> So a header such as the following should be processed fine:
> 
>   Content-Length:<0x09>110\r\n

Note that RFC 2616 you are quoting was obsoleted by RFC 7230.  In 
particular, line folding (the "[CRLF]" part of the grammar) is 
obsolete and must not be generated.  Modern syntax rules to refer 
to would be RFC 7230, section 3.2:

     header-field   = field-name ":" OWS field-value OWS

Where OWS is defined in section 3.2.3 as:

     OWS            = *( SP / HTAB )
                    ; optional whitespace

and text says that "a sender SHOULD generate the optional 
whitespace as a single SP" where an optional whitespace can 
improve readability.

However, we haven't seen any interoperability problems due to no 
HTAB support in nginx.  As such, instead of adding HTAB support it 
might be better to keep parsing strict.

[...]

-- 
Maxim Dounin
http://mdounin.ru/