a) The error does not have a single line. b) restarting does not fix it c) my nginx is no acting as proxy d) it happened twice and both times I fixed it by turning gzip off, restarting, and back on. e) I also noticed that I requested the image file with wget, get a full HTML file for the whole document, but named as if it were the image file.
wget https://x3x.us/index_files/image001.jpg but `stat image001.jpg' showed it was the entire text HTML file. http { client_max_body_size 1500M; include mime.types; # default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; tcp_nopush on; tcp_nodelay on; gzip on; gzip_vary on; gzip_min_length 10240; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml; gzip_disable "MSIE [1-6]\."; #keepalive_timeout 0; keepalive_timeout 65; types_hash_max_size 2048; proxy_headers_hash_max_size 1024; proxy_headers_hash_bucket_size 128; #gzip on; # error_log /var/log/nginx/error.log debug; error_log /var/log/nginx/error.log error; error_log /var/log/nginx/error.log crit; access_log /var/log/nginx/access.log; server { add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; default_type 'text/html; charset=UTF-8'; listen 208.78.161.6:80; server_name x3x.us; # Redirect all domains to https://x3x.us if ($scheme != "https") { return 301 https://x3x.us$request_uri; } } server { add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; default_type 'text/html; charset=UTF-8'; listen 208.78.161.6:443 ssl; server_name x3x.us; ssl_certificate /etc/letsencrypt/live/x3x.us/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/x3x.us/privkey.pem; root /static/duc/; location / { try_files $uri $uri/ /index.html; } } #server } #http On Wed, Feb 22, 2023 at 7:17 PM Maxim Dounin <mdou...@mdounin.ru> wrote: > Hello! > > On Wed, Feb 22, 2023 at 02:46:29PM -0500, Saint Michael wrote: > > > It's not a misconfiguration, is a huge bug. > > A wasted two days of sleep for something that is 100% a bug. > > Please read here: > > > https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle > > He mentions the same exact problem and also he points to > > > https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/ > > where the author says that Niginx will not fix it. > > So he already tried he was rebuffed. > > The fun fact is that the referenced article doesn't state "will > not fix", but rather "not a top priority". Further, proper error > propagation is available in nginx for about 10 years now, since > 2013 (http://hg.nginx.org/nginx/rev/d3eab5e2df5f, nginx 1.5.3). > Quoting CHANGES: > > *) Change: now after receiving an incomplete response from a backend > server nginx tries to send an available part of the response to a > client, and then closes client connection. > > As long as nginx have an information about an error, it will > preserve this information and propagate it to the client. > > Also note that it is only expected to make a difference if you are > using nginx as a proxy, not to directly serve files. And only in > case of errors. That is, if you are seeing the behaviour > described, it might be a good idea to focus on the errors in the > first place. > > I don't think it's anyhow related though, as switching gzip off > and back on, as seems to be "the fix" described in the first link, > is not going to help with anything. The important part is likely > "restarted the server", so I would rather assume that "the server" > (not sure if it refers to nginx or the whole server) was using an > incorrect configuration and/or was out of some resources, and > restart fixed it. > > Summing the above, if you want to find out what goes wrong in your > case - you may want to provide more details. If you don't, nobody > will be able to do it, unfortunately. > > The most basic thing I would recommend in the first place is to > look into nginx error log, it is likely to contain important > information if something goes wrong. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx mailing list > nginx@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx