Hello!

On Mon, Jan 20, 2020 at 05:29:25PM +0200, mstavrev@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/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel