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 <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


--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel