nginx serving corrupt images
Dan Swaney
justdan23 at gmail.com
Thu Feb 23 23:15:47 UTC 2023
I just ran your test and it works fine from Chrome and in Visual Studio
Code:
> wget https://x3x.us/index_files/image001.jpg
> StatusCode : 200
> StatusCode : 200
> StatusDescription : OK
> Content : {255, 216, 255, 224...}
> RawContent : HTTP/1.1 200 OK
> Connection: keep-alive
> Strict-Transport-Security: max-age=31536000;
> includeSubDomains
> Accept-Ranges: bytes
> Content-Length: 8834
> Content-Type: image/jpeg
> Date: Thu, 23 Feb 2023 23...
> Headers : {[Connection, keep-alive], [Strict-Transport-Security,
> max-age=31536000; includeSubDomains], [Accept-Ranges, bytes],
> [Content-Length, 8834]...}
> RawContentLength : 8834
[image: image.png]
On Wed, Feb 22, 2023 at 7:36 PM Saint Michael <venefax at gmail.com> wrote:
> 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
>>
> _______________________________________________
> 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/20230223/2358696f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 47810 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/2358696f/attachment-0001.png>
More information about the nginx
mailing list