nginx serving corrupt images
Dan Swaney
justdan23 at gmail.com
Fri Feb 24 00:07:58 UTC 2023
Now your image001.jpg is returning your home page:
[image: image.png]
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).
The tip was when it returns the content type as 'text/html' instead of
'image/jpg'.
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.
Looking at your previous cited partial nginx.conf:
- root /static/duc/;
- I usually define this in my 'location' base section only and drop
the initial '/' if it is relative to where NGINX is running.
- I then don't need it in any other 'location' sections for
sub-folders which have different security.
- You have it defined in your 'server' section.
- default_type 'text/html; charset=UTF-8';
- I usually define this at the top of my 'http' section.
- Normally I use 'default_type application/octet-stream;'
- You have it defined in your 'server' section.
- I see it returning your images as 'text/html'.
- try_files $uri $uri/ /index.html;
- I usually define a default 'index' if at the root and nothing else is
added.
- For example: 'index index.html;'
- Remove the try_files like recommended earlier.
- If you need to restrict access to specific folder URL mappings,
then define a location of the URL mapping and add one line...
- 'deny all;'
- Otherwise leave it open to all sub URLs by doing nothing more
but use a single 'location /' rule.
On Thu, Feb 23, 2023 at 6:15 PM Dan Swaney <justdan23 at gmail.com> wrote:
> 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/152d08d0/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/152d08d0/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 282588 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/152d08d0/attachment-0003.png>
More information about the nginx
mailing list