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