4

Without restart or modification of config, nginx is sending incomplete responses sometimes. Today, I could reproduce well, but still don't know what's wrong or how to fix.

I put a 5MB file to the site's location/alias path that nginx is configured to use. There is no php5-fpm, modules etc. only nginx for serving static files.

When testing, there is no other user accessing the server, no http access except my test requests.

The download fails and Google Chrome shows in traffic log, that there were 2 requests, although I put the http url for the download only ONCE and there was no redirect or other 2nd request initiated by myself.

Same issue at server's access.log, too:

TEST1

[14/May/2014:14:06:53 +0200] "GET /dev/test_test.m4v HTTP/1.1" 206 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"

[14/May/2014:14:06:53 +0200] "GET /dev/test_test.m4v HTTP/1.1" 200 130680 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.10

[14/May/2014:14:07:15 +0200] "GET /dev/test_test.m4v HTTP/1.1" 206 1 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"

[14/May/2014:14:07:15 +0200] "GET /dev/test_test.m4v HTTP/1.1" 200 114684 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.10

You can see that theere is always one request with response size=1 and another one with mixed size, but >1. However, the result in the browser is always the same. => broken response, failed download.

For making sure, it's not related to http status/response 206, I add max_ranges 0; to the config and retry -> test2.

TEST2

[14/May/2014:14:11:36 +0200] "GET /dev/test_test.m4v HTTP/1.1" 200 152460 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"

[14/May/2014:14:11:38 +0200] "GET /dev/test_test.m4v HTTP/1.1" 200 142296 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36"

Same result in the browser. Always failed download/request and the size in access.log is always different, like random chunk or response size.

server status: iowait, RAM, cpu are almost idle. There is no high load or limitation.

Is this a known issue or bug or do You know how to fix this?

Community
  • 1
ledy
  • 515
  • 1
  • 6
  • 15
  • Have you tried to download with wget/curl? – Alexey Ten May 14 '14 at 12:36
  • download with wget/curl is OK. but Chrome and Safari browser on windows and unix fail for unknown reason. in access.log, we can see that also other visitors are facing the issue. – ledy May 14 '14 at 17:50
  • Did you find any solution to this? We're running into this same issue. Every request returns files chunked with different filesize (WITHOUT the 'chunked' header, all of them return 200). – elboletaire Jan 02 '17 at 16:03
  • https://serverfault.com/questions/535889/disabling-206-partial-content-responses-on-nginx ? – Marcel Feb 04 '19 at 18:06
  • https://serverfault.com/a/535890/164840 ? – Marcel Feb 04 '19 at 18:06

1 Answers1

1

With a scenario as simple as this, I'm pretty sure you have a firewall, IDS/IPS device or something else in front of your nginx server disturbing downloads. If in doubt, contact your ISP.

Janne Pikkarainen
  • 31,454
  • 4
  • 56
  • 78
  • i tried with smartphone via mobile instead of local wifi, too, and got the same problem. also, access.log shows similar. first a 1size response, followed by another download request with "random" size, whenever i try to refresh. – ledy May 14 '14 at 17:51
  • 2
    i can confirm again, this is not a firewall or client-side bug. it's caused by the server. one more fact, that we noticed. only chrome browsers seem to have issues. firefox never had this problem. with chrome, sometimes it's ending up with empty response; other times the same request is successful, without any issues. i will add further logging to the question description on top. – ledy May 30 '14 at 16:49