<div dir="ltr"><div class="gmail_default" style="font-size:small">You have the root inside the location:</div><div class="gmail_default" style="font-size:small"><span style="font-family:monospace">location / {</span><br style="font-family:monospace"><span style="font-family:monospace">            root   html;</span><br></div><div class="gmail_default" style="font-size:small"><span style="font-family:monospace"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:monospace">I had it outside</span></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">root static/duc/;</div><br>        location / {<br><div class="gmail_default" style="font-size:small"><span style="font-family:monospace"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:monospace">What is the correct way to do this?</span></div><div class="gmail_default" style="font-size:small"><span style="font-family:monospace"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:monospace"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023 at 9:42 PM Saint Michael <<a href="mailto:venefax@gmail.com">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">ok, so I am not insane. Is good to know.</div><div class="gmail_default" style="font-size:small">23/02/24 02:38:44 [notice] 174292#0: using the "epoll" event method<br>2023/02/24 02:38:44 [notice] 174292#0: openresty/<a href="http://1.21.4.1" target="_blank">1.21.4.1</a><br>2023/02/24 02:38:44 [notice] 174292#0: built by gcc 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) <br>2023/02/24 02:38:44 [notice] 174292#0: OS: Linux 6.1.10-1-pve<br>2023/02/24 02:38:44 [notice] 174292#0: getrlimit(RLIMIT_NOFILE): 1000000:1000000<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">can you please file a bug? They would not talk to me because  I am a newbie.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yours</div><div class="gmail_default" style="font-size:small">Federico</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 Thu, Feb 23, 2023 at 9:33 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 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" 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"><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>
_______________________________________________<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>