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
