<div dir="ltr"><div>Hello,</div><div><br></div><div>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.</div><div> 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.<br></div><div>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.</div><div><br></div><div>Best Regards</div><div>M. Stavrev<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 23, 2020 at 9:29 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Mon, Jan 20, 2020 at 05:29:25PM +0200, <a href="mailto:mstavrev@gmail.com" target="_blank">mstavrev@gmail.com</a> wrote:<br>
<br>
> # HG changeset patch<br>
> # User Marin Stavrev<br>
> # Date 1579526641 -7200<br>
> #      Mon Jan 20 15:24:01 2020 +0200<br>
> # Node ID bf238762fdaf03383c2f3c3718c401e6141e3935<br>
> # Parent  6439ef81e37dfccfc3a8c57fed278bf56014ef39<br>
> Fix for the HT on request headers problem (#1752)<br>
> <br>
> When client send HTTP request with a header of Content-Length that starts with<br>
> horizontal tab character (HT=0x09), Nginx responds with HTTP 400 Bad Request.<br>
> According to HTTP RFC2616 section 4.2, "... The field value MAY be preceded by<br>
> any amount of LWS, though a single SP is preferred.". The difinition of LWS is:<br>
> <br>
>   LWS = [CRLF] 1*( SP | HT )<br>
> <br>
> So a header such as the following should be processed fine:<br>
> <br>
>   Content-Length:<0x09>110\r\n<br>
<br>
Note that RFC 2616 you are quoting was obsoleted by RFC 7230.  In <br>
particular, line folding (the "[CRLF]" part of the grammar) is <br>
obsolete and must not be generated.  Modern syntax rules to refer <br>
to would be RFC 7230, section 3.2:<br>
<br>
     header-field   = field-name ":" OWS field-value OWS<br>
<br>
Where OWS is defined in section 3.2.3 as:<br>
<br>
     OWS            = *( SP / HTAB )<br>
                    ; optional whitespace<br>
<br>
and text says that "a sender SHOULD generate the optional <br>
whitespace as a single SP" where an optional whitespace can <br>
improve readability.<br>
<br>
However, we haven't seen any interoperability problems due to no <br>
HTAB support in nginx.  As such, instead of adding HTAB support it <br>
might be better to keep parsing strict.<br>
<br>
[...]<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div>