Hello! On Fri, Feb 14, 2020 at 01:57:49PM +0200, Marin Stavrev wrote:
> Is there any update about this one, or it is a closed case for the Nginx > team? In this particular case I tend to think that fixing the camera to use SP instead of HTAB is probably a better option. Alternatively, consider maintaining a local patch if you want to maintain interoperability with a particular IP camera. We might consider adding HTAB support if more interoperability problems will be reported. > > Best Regards > Marin > > On Fri, Jan 24, 2020 at 9:07 AM Marin Stavrev <[email protected]> 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 <[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 -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
