Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#264 closed enhancement (invalid)

ngx_http_parse.c does'not like LFCR

Reported by: Martin Loehnertz Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.2.x
Keywords: parse headers Cc:
uname -a: Linux <my server ip> 2.6.32-028stab099.3 #1 SMP Wed Mar 7 15:20:22 MSK 2012 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.2.5
built by gcc 4.4.5 (Debian 4.4.5-8)
TLS SNI support enabled
configure arguments: --user=www-data --group=www-data --with-http_ssl_module --without-http_geo_module --without-http_memcached_module --without-http_split_clients_module --without-http_ssi_module --without-http_uwsgi_module --with-ipv6 --with-http_sub_module --without-http_fastcgi_module


I tried to use the scgi-lib from
and ran into a problem of malformed headers from the upstream server.
I tracked it back to the fact that in the example code from they send
\n\r instead of \r\n as end of line marker.
Replacing this DOS Madness by a normal Unix \n fixed the problem.

Still I think the following code found throughout ngx_http_parse.c is susceptible to this problem
and there does not seem to be a standard forbidding \n\r. So a minor correction might help to prevent further complains.

case CR:

r->http_minor = 9;
state = sw_almost_done;

case LF:

r->http_minor = 9;
goto done;

Change History (1)

comment:1 by Maxim Dounin, 12 years ago

Resolution: invalid
Status: newclosed

The LF CR isn't correct line ending for DOS, correct one is CR LF. Following robustness principle, nginx accepts both standard CR LF (aka DOS) and bare LF. Accepting incorrect LF CR would make things worse, not better (not to mention it will require lookahead and guessing).

Note: See TracTickets for help on using tickets.