nginx serving corrupt images

[Saint Michael]

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 <mdounin at 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 at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/45e0aaaa/attachment.htm>