Opened 10 years ago
Closed 10 years ago
#687 closed defect (wontfix)
Keep-alive with fastcgi not working with HEAD
| Reported by: | Michael Bonfils | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.6.x |
| Keywords: | fastcgi keepalive head | Cc: | patrick.dos.santos@… |
| uname -a: | Linux ubuntu14-vm 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.7.8
built by gcc 4.8.2 (Ubuntu 4.8.2-19ubuntu1) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_spdy_module --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed' --with-ipv6 |
||
Description
During our test, we found that while issue HEAD requests to nginx on fastcgi backend, we found that it doesn't reuse TCP connection to fastcgi backend for HEAD requests.
How to reproduce :
$ netstat -tupan | grep 1039 tcp 0 0 0.0.0.0:1039 0.0.0.0:* LISTEN 23795/dewpoint.fcgi $ curl -I http://localhost http://localhost/README http://localhost/README http://localhost/README http://localhost/README http://localhost/README http://localhost/README http://localhost http://localhost http://localhost/README http://localhost/README http://localhost $ netstat -tupan | grep 1039 tcp 0 0 0.0.0.0:1039 0.0.0.0:* LISTEN 23795/dewpoint.fcgi tcp 0 0 127.0.0.1:39797 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39802 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39801 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39790 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39798 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39805 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39796 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39791 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39794 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39800 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39795 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39799 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39804 127.0.0.1:1039 TIME_WAIT - tcp 0 0 127.0.0.1:39803 127.0.0.1:1039 TIME_WAIT -
In error.log in debug mode ::
2014/12/23 15:33:50 [info] 27766#0: *1 client 127.0.0.1 closed keepalive connection
With GET requests, keep alive between nginx and fastcgi backend is ok
$ netstat -tupan | grep 1039 tcp 0 0 0.0.0.0:1039 0.0.0.0:* LISTEN 23795/dewpoint.fcgi $ curl -v http://localhost http://localhost/README http://localhost/README http://localhost/README http://localhost/README http://localhost/README http://localhost/README http://localhost http://localhost http://localhost/README http://localhost/README http://localhost $ netstat -tupan | grep 1039 tcp 0 0 0.0.0.0:1039 0.0.0.0:* LISTEN 23795/dewpoint.fcgi tcp 0 1024 127.0.0.1:1039 127.0.0.1:39808 ESTABLISHED 23795/dewpoint.fcgi tcp 0 0 127.0.0.1:39808 127.0.0.1:1039 ESTABLISHED 27695/nginx: worker
Issue was reproduced in 1.6.2 and 1.7.8
Attachments (2)
Change History (3)
by , 10 years ago
| Attachment: | dump_head.pcap added |
|---|
comment:1 by , 10 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Yes, this is expected behaviour. In case of a HEAD request (and in other cases when response body isn't returned) we do not read the response body from a backend (if any), and close the connection instead.
Note:
See TracTickets
for help on using tickets.
Dump of network between nginx and fastcgi backend