<div dir="ltr">I tried to reproduce it with a simple web page and I'm seeing the issue which I believe you are having.<div><br></div><div>By default, NGINX seems to default to some limit of 15k on responses of images returned directly.</div><div><br></div><div>While the error.log in debug mode shows it constructs the response with the right content length, it fails to return a response if the file is over 15k.</div><div><br></div><div>I'm using a build I did from NGINX 1.23.3. While I know I have returned files larger than this in proxy mode. This seems to be happening in normal web server page mode.</div><div><br></div><div><img src="cid:ii_lehwhvfp3" alt="image.png" width="562" height="304"><br></div><div><br></div><div><br></div><div>I even tried to increase it by adding:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace"> location / {<br> root html;<br> index index.html index.htm favicon.ico;<br> <br> types {<br> text/html html;<br> image/gif gif;<br> application/octetstream jpg;<br> application/octetstream png;<br> }<br> <br> set $max_image_size 50000;<br> client_max_body_size 50000;<br> }</font><br></blockquote></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 8:09 PM Dan Swaney <<a href="mailto:justdan23@gmail.com">justdan23@gmail.com</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"><div dir="ltr"><div>Try this:</div><ol><li>At the very top of your nginx.conf file, add a definition:<br><br> error_log logs/error.log debug;<br><br></li><li>Within your nginx install directory (where nginx.exe exists), create a 'logs' folder if one does not exist.</li><li>Restart nginx.exe (if running as a Windows Service with NSSM, then restart the service).</li><li>If NGINX does not start...</li><ul><li>Check the 'error.log' as it will tell you if your nginx.conf has something weird in it that it doesn't like.</li></ul><li>If NGINX started successfully...</li><ul><li>Run your test from your client browser.</li><li>Go back to the Server and check your 'error.log' and look for the URL request. </li><li>It will show you everything it does with routing or looking for files.</li></ul></ol></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 7:22 PM Saint Michael <<a href="mailto:venefax@gmail.com" target="_blank">venefax@gmail.com</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"><div dir="ltr"><div class="gmail_default" style="font-size:small">Now it remains broken and I have no idea how to fix it. I guess is caching bad copies of the pictures.</div><div class="gmail_default" style="font-size:small">I re-uploaded the two images.</div><div class="gmail_default" style="font-size:small">Kindly let me know if this is "normal"</div><div class="gmail_default" style="font-size:small"><img src="cid:ii_lehsds9s2" alt="image.png" width="562" height="346"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 7:08 PM Dan Swaney <<a href="mailto:justdan23@gmail.com" target="_blank">justdan23@gmail.com</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"><div dir="ltr">Now your image001.jpg is returning your home page:<div><img src="cid:ii_lehr3yag1" alt="image.png" width="562" height="299"><br></div><div><br></div><div>If I had to guess, your location routing is re-routing all sub-urls to your base URL at '/' which is defaulting to your index.html (or whatever you have set for your default).</div><div>The tip was when it returns the content type as 'text/html' instead of 'image/jpg'.</div><div><br></div><div>As Maxim cited, your 'location' directives are for routing URL paths and not files. Think of the external viewed URL and the internal routed URL location.</div><div><br></div><div>Looking at your previous cited partial nginx.conf:<br><ul><li>root /static/duc/; </li><ul><li>I usually define this in my 'location' base section only and drop the initial '/' if it is relative to where NGINX is running.</li><ul><li>I then don't need it in any other 'location' sections for sub-folders which have different security.</li></ul><li>You have it defined in your 'server' section.</li></ul></ul><ul><li>default_type 'text/html; charset=UTF-8';</li><ul><li>I usually define this at the top of my 'http' section.</li><ul><li>Normally I use 'default_type application/octet-stream;'</li></ul><li>You have it defined in your 'server' section.</li><li>I see it returning your images as 'text/html'.<br><br></li></ul><li>try_files $uri $uri/ /index.html;<br></li><ul><li>I usually define a default 'index' if at the root and nothing else is added.</li><ul><li>For example: 'index index.html;'</li></ul><li>Remove the try_files like recommended earlier.</li><li>If you need to restrict access to specific folder URL mappings, then define a location of the URL mapping and add one line...</li><ul><li>'deny all;'</li><li>Otherwise leave it open to all sub URLs by doing nothing more but use a single 'location /' rule.</li></ul></ul></ul></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 6:15 PM Dan Swaney <<a href="mailto:justdan23@gmail.com" target="_blank">justdan23@gmail.com</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"><div dir="ltr">I just ran your test and it works fine from Chrome and in Visual Studio Code:<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> wget <a href="https://x3x.us/index_files/image001.jpg" target="_blank">https://x3x.us/index_files/image001.jpg</a><br>StatusCode : 200<br>StatusCode : 200<br>StatusDescription : OK<br>Content : {255, 216, 255, 224...}<br>RawContent : HTTP/1.1 200 OK<br> Connection: keep-alive<br> Strict-Transport-Security: max-age=31536000; includeSubDomains<br> Accept-Ranges: bytes<br> Content-Length: 8834<br> Content-Type: image/jpeg<br> Date: Thu, 23 Feb 2023 23...<br>Headers : {[Connection, keep-alive], [Strict-Transport-Security, max-age=31536000; includeSubDomains], [Accept-Ranges, bytes], <br> [Content-Length, 8834]...}<br>RawContentLength : 8834</blockquote><div><br></div><img src="cid:ii_lehq2tei0" alt="image.png" width="494" height="112"><br><div> </div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 22, 2023 at 7:36 PM Saint Michael <<a href="mailto:venefax@gmail.com" target="_blank">venefax@gmail.com</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"><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" target="_blank">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" target="_blank">208.78.161.6:80</a>;<br> server_name <a href="http://x3x.us" target="_blank">x3x.us</a>;<br><br> # Redirect all domains to <a href="https://x3x.us" target="_blank">https://x3x.us</a><br> if ($scheme != "https") {<br> return 301 <a href="https://x3x.us" target="_blank">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" target="_blank">208.78.161.6:443</a> ssl;<br> server_name <a href="http://x3x.us" target="_blank">x3x.us</a>;<br><br> ssl_certificate /etc/letsencrypt/live/<a href="http://x3x.us/fullchain.pem" target="_blank">x3x.us/fullchain.pem</a>;<br> ssl_certificate_key /etc/letsencrypt/live/<a href="http://x3x.us/privkey.pem" target="_blank">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" target="_blank">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>
_______________________________________________<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>
</blockquote></div>
_______________________________________________<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>
_______________________________________________<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>
</blockquote></div>