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

[Marin Stavrev]

Hello,

Is there any update about this one, or it is a closed case for the Nginx
team?

Best Regards
Marin

On Fri, Jan 24, 2020 at 9:07 AM Marin Stavrev <mstavrev at gmail.com> wrote:

> Hello,
>
> I can understand your point, but still RFC 7230 defines OWS to allow HTAB
> and the therm used to suggest a single SP is SHOULD (recommendation) not
> MUST (mandatory). Thus, Nginx is not fully compliant.
> I would never post such a change if it wasn't really needed - I am not
> pushing for this change just out of love for RFC compliance.I have this
> issue causing problems with some Chinese IP cameras and NVRs that are
> generating such headers. I understand this is quite rare, and to be frank
> this is the only case I had personally seen such a (lousy) HTTP
> implementation. Unfortunately, I don't have any control over their FW and
> thus needed this fix on the server side.
> I know it does not matter much, but both Apache and Microsoft IIS handle
> such headers as expected and do not treat the request as a bad one as Nginx
> currently does.
>
> Best Regards
> M. Stavrev
>
> On Thu, Jan 23, 2020 at 9:29 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> 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/
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200214/c237e341/attachment.htm>