#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 |
||
Description
I tried to use the scgi-lib from
http://www.xamuel.com/scgilib/
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 xamuel.com 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;
break;
case LF:
r->http_minor = 9;
goto done;
Note:
See TracTickets
for help on using tickets.
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).