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 <[email protected]> wrote: > Hello! > > On Mon, Jan 20, 2020 at 05:29:25PM +0200, [email protected] 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 > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel >
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
