Welcome! Log In Create A New Profile

Advanced

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

Marin Stavrev
February 14, 2020 07:00AM
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@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@mdounin.ru> wrote:
>
>> 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
>>
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

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

Anonymous User 154 January 20, 2020 10:30AM

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

Maxim Dounin 27 January 23, 2020 02:30PM

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

Marin Stavrev 41 January 24, 2020 02:10AM

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

Marin Stavrev 24 February 14, 2020 07:00AM

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

Maxim Dounin 27 February 18, 2020 11:04AM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 65
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready