To use HTTP2, you have to configure the build to include it. Same goes for
Kerberos GSSAPI SPNEGO Authentication support with the SPNEGO Module for
NGINX.
> nginx version: nginx/1.23.3
> built by cl 19.34.31937 for x64
> *built with OpenSSL 3.1.0-beta1-dev*
> TLS SNI support enabled
> configure arguments: --with-cc=cl --builddir=objs --with-debug --prefix=.
> --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
> --http-log-path=logs/access.log --error-log-path=logs/error.log
> --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp
> --http-proxy-temp-path=temp/proxy_temp
> --http-fastcgi-temp-path=temp/fastcgi_temp
> --http-scgi-temp-path=temp/scgi_temp --http-uwsgi-temp-path=temp/uwsgi_temp
> --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre2
> --with-zlib=objs/lib/zlib --with-select_module *--with-http_v2_module*
> --with-http_realip_module --with-http_addition_module
> --with-http_sub_module --with-http_dav_module
> --with-http_stub_status_module --with-http_flv_module
> --with-http_mp4_module --with-http_gunzip_module
> --with-http_gzip_static_module --with-http_auth_request_module
> --with-http_random_index_module --with-http_secure_link_module
> --with-http_slice_module --with-mail --with-stream --with-http_ssl_module
> --with-mail_ssl_module --with-stream_ssl_module
> --with-openssl=objs/lib/openssl
> --add-module=objs/lib/spnego-http-auth-nginx-module --with-cc-opt='-I
> objs/lib/krb5/objs/include'
>
On Thu, Feb 23, 2023 at 10:30 PM Saint Michael <venefax at gmail.com> wrote:
> I enabled http2 but it fails
>
> nginx: [emerg] the "http2" parameter requires ngx_http_v2_module in
> /etc/federico/x3x.conf:17
>
> On Thu, Feb 23, 2023 at 10:25 PM Saint Michael <venefax at gmail.com> wrote:
>
>> can we add that at the top level? like a global value?
>>
>>
>> On Thu, Feb 23, 2023 at 10:17 PM Dan Swaney <justdan23 at gmail.com> wrote:
>>
>>> See my earlier response above for details. It works when you reduce the
>>> ssl_buffer_size to 4k. You can try 8k for performance.
>>> (Correction: use the 'server' section for this setting.)
>>>
>>> server {
>>> ...
>>> ssl_buffer_size 4k;
>>> }
>>>
>>> Reference to setting is on this page:
>>>
>>> https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/
>>>
>>>
>>> The bug happens to be within the OpenSSL library I believe, but I found
>>> when reducing the buffer size to 4k, it worked for my test.
>>> There is a bug when it operates with the default of 16k and it fails to
>>> write out the response in 16k chunks, but does work with 4k chunks.
>>>
>>> On Thu, Feb 23, 2023 at 10:06 PM Saint Michael <venefax at gmail.com>
>>> wrote:
>>>
>>>> Please read this, it's from 2011/11/04, and it hasn't been fixed :
>>>>
>>>> https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
>>>>
>>>>
>>>> On Thu, Feb 23, 2023 at 9:43 PM Dan Swaney <justdan23 at gmail.com> wrote:
>>>>
>>>>> Ah-ah...I caught the NGINX failure in the SSL response:
>>>>>
>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http filename:
>>>>>> "./html/images/image001.jpg"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 add cleanup:
>>>>>> 000002DC83A7CBE8
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http static fd: 732
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http set discard body
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map started
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 parse header: "Cookie:
>>>>>> SessionId SessionId="
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map started
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map: "" ""
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: ""
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map: "" ""
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy:
>>>>>> "SessionId SessionId="
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: ""
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: ";AuthId="
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: "SessionId
>>>>>> SessionId="
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: "
>>>>>> SessionId="
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var:
>>>>>> "ab3e389a16b819b5477309665cfcc4672f47d5657e1c154381c6eb8336963721"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: "; Domain=
>>>>>> win10-web-svr.dreamstone.com; Path=/; HttpOnly; Secure"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 HTTP/1.1 200 OK
>>>>>> Server: nginx/1.23.3
>>>>>> Date: Fri, 24 Feb 2023 02:24:49 GMT
>>>>>> Content-Type: application/octetstream
>>>>>> *Content-Length: 123197*
>>>>>> Last-Modified: Wed, 30 Nov 2022 19:41:21 GMT
>>>>>> Connection: keep-alive
>>>>>> ETag: "6387b1e1-1e13d"
>>>>>> Strict-Transport-Security: max-age=15768000; preload
>>>>>> X-Frame-Options: SAMEORIGIN
>>>>>> X-XSS-Protection: 1
>>>>>> X-Content-Type-Options: nosniff
>>>>>> Referred-Policy: strict-origin
>>>>>> Set-Cookie: SessionId SessionId=;AuthId=SessionId SessionId=
>>>>>> SessionId=ab3e389a16b819b5477309665cfcc4672f47d5657e1c154381c6eb8336963721;
>>>>>> Domain=win10-web-svr.dreamstone.com; Path=/; HttpOnly; Secure
>>>>>> Accept-Ranges: bytes
>>>>>>
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write new buf t:1 f:0
>>>>>> 000002DC83A7E2F0, pos 000002DC83A7E2F0, size: 626 file: 0, size: 0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter: l:0 f:0
>>>>>> s:626
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http output filter
>>>>>> "/images/image001.jpg?"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http copy filter:
>>>>>> "/images/image001.jpg?"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 malloc:
>>>>>> 000002DC83A87340:32768
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http postpone filter
>>>>>> "/images/image001.jpg?" 000002DC83A7E658
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write old buf t:1 f:0
>>>>>> 000002DC83A7E2F0, pos 000002DC83A7E2F0, size: 626 file: 0, size: 0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write new buf t:1 f:0
>>>>>> 000002DC83A87340, pos 000002DC83A87340, size: 32768 file: 0, size: 0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter: l:0 f:1
>>>>>> s:33394
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter limit
>>>>>> 2097152
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 malloc:
>>>>>> 000002DC83A8F350:16384
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL buf copy: 626
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL buf copy: 15758
>>>>>> *2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL to write: 16384*
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: ssl remove session: B87DD7B9:32
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: shmtx lock
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: shmtx unlock
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL_write: -1
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL_get_error: 1
>>>>>>
>>>>>> *2023/02/23 21:24:49 [crit] 4768#4528: *1 SSL_write() failed (SSL:
>>>>>> error:0A0C0103:SSL routines::internal error) while sending response to
>>>>>> client, client: 192.168.80.130, server: win10-web-svr.dreamstone.com
>>>>>> <http://win10-web-svr.dreamstone.com>, request: "GET /images/image001.jpg
>>>>>> HTTP/1.1", host: "win10-web-svr.dreamstone.com
>>>>>> <http://win10-web-svr.dreamstone.com>", referrer:
>>>>>> "https://win10-web-svr.dreamstone.com/
>>>>>> <https://win10-web-svr.dreamstone.com/>"*2023/02/23 21:24:49 [debug]
>>>>>> 4768#4528: *1 http write filter FFFFFFFFFFFFFFFF
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http copy filter: -1
>>>>>> "/images/image001.jpg?"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http finalize request: -1,
>>>>>> "/images/image001.jpg?" a:1, c:1
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate request
>>>>>> count:1
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate cleanup
>>>>>> count:1 blk:0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http posted request:
>>>>>> "/images/image001.jpg?"
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate handler
>>>>>> count:1
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http request count:1 blk:0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http close request
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http log handler
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 run cleanup:
>>>>>> 000002DC83A7CBE8
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 file cleanup: fd:732
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A87340
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7BC00,
>>>>>> unused: 0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7DC20,
>>>>>> unused: 1167
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 close http connection: 500
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 select del event fd:500
>>>>>> ev:768
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 reusable connection: 0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A647C0
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A8F350
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC8332EAB0,
>>>>>> unused: 12
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7DA10,
>>>>>> unused: 384
>>>>>>
>>>>>
>>>>> On Thu, Feb 23, 2023 at 9:32 PM Dan Swaney <justdan23 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I tried to reproduce it with a simple web page and I'm seeing the
>>>>>> issue which I believe you are having.
>>>>>>
>>>>>> By default, NGINX seems to default to some limit of 15k on responses
>>>>>> of images returned directly.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>>
>>>>>> I even tried to increase it by adding:
>>>>>>
>>>>>> location / {
>>>>>>> root html;
>>>>>>> index index.html index.htm favicon.ico;
>>>>>>>
>>>>>>> types {
>>>>>>> text/html html;
>>>>>>> image/gif gif;
>>>>>>> application/octetstream jpg;
>>>>>>> application/octetstream png;
>>>>>>> }
>>>>>>>
>>>>>>> set $max_image_size 50000;
>>>>>>> client_max_body_size 50000;
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> On Thu, Feb 23, 2023 at 8:09 PM Dan Swaney <justdan23 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Try this:
>>>>>>>
>>>>>>> 1. At the very top of your nginx.conf file, add a definition:
>>>>>>>
>>>>>>> error_log logs/error.log debug;
>>>>>>>
>>>>>>> 2. Within your nginx install directory (where nginx.exe exists),
>>>>>>> create a 'logs' folder if one does not exist.
>>>>>>> 3. Restart nginx.exe (if running as a Windows Service with NSSM,
>>>>>>> then restart the service).
>>>>>>> 4. If NGINX does not start...
>>>>>>> - Check the 'error.log' as it will tell you if your
>>>>>>> nginx.conf has something weird in it that it doesn't like.
>>>>>>> 5. If NGINX started successfully...
>>>>>>> - Run your test from your client browser.
>>>>>>> - Go back to the Server and check your 'error.log' and look
>>>>>>> for the URL request.
>>>>>>> - It will show you everything it does with routing or looking
>>>>>>> for files.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 23, 2023 at 7:22 PM Saint Michael <venefax at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Now it remains broken and I have no idea how to fix it. I guess is
>>>>>>>> caching bad copies of the pictures.
>>>>>>>> I re-uploaded the two images.
>>>>>>>> Kindly let me know if this is "normal"
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>> On Thu, Feb 23, 2023 at 7:08 PM Dan Swaney <justdan23 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>>> 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/6d0d6546/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/6d0d6546/attachment-0004.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/6d0d6546/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 111869 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/6d0d6546/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 193204 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/6d0d6546/attachment-0007.png>
Saint, can you also run 'nginx -V' and drop your build configuration here
in this thread?
On Thu, Feb 23, 2023 at 10:41 PM Dan Swaney <justdan23 at gmail.com> wrote:
> To use HTTP2, you have to configure the build to include it. Same goes
> for Kerberos GSSAPI SPNEGO Authentication support with the SPNEGO Module
> for NGINX.
>
>
>> nginx version: nginx/1.23.3
>> built by cl 19.34.31937 for x64
>> *built with OpenSSL 3.1.0-beta1-dev*
>> TLS SNI support enabled
>> configure arguments: --with-cc=cl --builddir=objs --with-debug --prefix=.
>> --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
>> --http-log-path=logs/access.log --error-log-path=logs/error.log
>> --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp
>> --http-proxy-temp-path=temp/proxy_temp
>> --http-fastcgi-temp-path=temp/fastcgi_temp
>> --http-scgi-temp-path=temp/scgi_temp --http-uwsgi-temp-path=temp/uwsgi_temp
>> --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre2
>> --with-zlib=objs/lib/zlib --with-select_module *--with-http_v2_module*
>> --with-http_realip_module --with-http_addition_module
>> --with-http_sub_module --with-http_dav_module
>> --with-http_stub_status_module --with-http_flv_module
>> --with-http_mp4_module --with-http_gunzip_module
>> --with-http_gzip_static_module --with-http_auth_request_module
>> --with-http_random_index_module --with-http_secure_link_module
>> --with-http_slice_module --with-mail --with-stream --with-http_ssl_module
>> --with-mail_ssl_module --with-stream_ssl_module
>> --with-openssl=objs/lib/openssl
>> --add-module=objs/lib/spnego-http-auth-nginx-module --with-cc-opt='-I
>> objs/lib/krb5/objs/include'
>>
>
>
> On Thu, Feb 23, 2023 at 10:30 PM Saint Michael <venefax at gmail.com> wrote:
>
>> I enabled http2 but it fails
>>
>> nginx: [emerg] the "http2" parameter requires ngx_http_v2_module in
>> /etc/federico/x3x.conf:17
>>
>> On Thu, Feb 23, 2023 at 10:25 PM Saint Michael <venefax at gmail.com> wrote:
>>
>>> can we add that at the top level? like a global value?
>>>
>>>
>>> On Thu, Feb 23, 2023 at 10:17 PM Dan Swaney <justdan23 at gmail.com> wrote:
>>>
>>>> See my earlier response above for details. It works when you reduce
>>>> the ssl_buffer_size to 4k. You can try 8k for performance.
>>>> (Correction: use the 'server' section for this setting.)
>>>>
>>>> server {
>>>> ...
>>>> ssl_buffer_size 4k;
>>>> }
>>>>
>>>> Reference to setting is on this page:
>>>>
>>>> https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/
>>>>
>>>>
>>>> The bug happens to be within the OpenSSL library I believe, but I found
>>>> when reducing the buffer size to 4k, it worked for my test.
>>>> There is a bug when it operates with the default of 16k and it fails to
>>>> write out the response in 16k chunks, but does work with 4k chunks.
>>>>
>>>> On Thu, Feb 23, 2023 at 10:06 PM Saint Michael <venefax at gmail.com>
>>>> wrote:
>>>>
>>>>> Please read this, it's from 2011/11/04, and it hasn't been fixed :
>>>>>
>>>>> https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
>>>>>
>>>>>
>>>>> On Thu, Feb 23, 2023 at 9:43 PM Dan Swaney <justdan23 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Ah-ah...I caught the NGINX failure in the SSL response:
>>>>>>
>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http filename:
>>>>>>> "./html/images/image001.jpg"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 add cleanup:
>>>>>>> 000002DC83A7CBE8
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http static fd: 732
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http set discard body
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map started
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 parse header: "Cookie:
>>>>>>> SessionId SessionId="
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map started
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map: "" ""
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: ""
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map: "" ""
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy:
>>>>>>> "SessionId SessionId="
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: ""
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy:
>>>>>>> ";AuthId="
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var:
>>>>>>> "SessionId SessionId="
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: "
>>>>>>> SessionId="
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var:
>>>>>>> "ab3e389a16b819b5477309665cfcc4672f47d5657e1c154381c6eb8336963721"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: ";
>>>>>>> Domain=win10-web-svr.dreamstone.com; Path=/; HttpOnly; Secure"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 HTTP/1.1 200 OK
>>>>>>> Server: nginx/1.23.3
>>>>>>> Date: Fri, 24 Feb 2023 02:24:49 GMT
>>>>>>> Content-Type: application/octetstream
>>>>>>> *Content-Length: 123197*
>>>>>>> Last-Modified: Wed, 30 Nov 2022 19:41:21 GMT
>>>>>>> Connection: keep-alive
>>>>>>> ETag: "6387b1e1-1e13d"
>>>>>>> Strict-Transport-Security: max-age=15768000; preload
>>>>>>> X-Frame-Options: SAMEORIGIN
>>>>>>> X-XSS-Protection: 1
>>>>>>> X-Content-Type-Options: nosniff
>>>>>>> Referred-Policy: strict-origin
>>>>>>> Set-Cookie: SessionId SessionId=;AuthId=SessionId SessionId=
>>>>>>> SessionId=ab3e389a16b819b5477309665cfcc4672f47d5657e1c154381c6eb8336963721;
>>>>>>> Domain=win10-web-svr.dreamstone.com; Path=/; HttpOnly; Secure
>>>>>>> Accept-Ranges: bytes
>>>>>>>
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write new buf t:1 f:0
>>>>>>> 000002DC83A7E2F0, pos 000002DC83A7E2F0, size: 626 file: 0, size: 0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter: l:0 f:0
>>>>>>> s:626
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http output filter
>>>>>>> "/images/image001.jpg?"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http copy filter:
>>>>>>> "/images/image001.jpg?"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 malloc:
>>>>>>> 000002DC83A87340:32768
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http postpone filter
>>>>>>> "/images/image001.jpg?" 000002DC83A7E658
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write old buf t:1 f:0
>>>>>>> 000002DC83A7E2F0, pos 000002DC83A7E2F0, size: 626 file: 0, size: 0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write new buf t:1 f:0
>>>>>>> 000002DC83A87340, pos 000002DC83A87340, size: 32768 file: 0, size: 0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter: l:0 f:1
>>>>>>> s:33394
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter limit
>>>>>>> 2097152
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 malloc:
>>>>>>> 000002DC83A8F350:16384
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL buf copy: 626
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL buf copy: 15758
>>>>>>> *2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL to write: 16384*
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: ssl remove session:
>>>>>>> B87DD7B9:32
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: shmtx lock
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: shmtx unlock
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL_write: -1
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL_get_error: 1
>>>>>>>
>>>>>>> *2023/02/23 21:24:49 [crit] 4768#4528: *1 SSL_write() failed (SSL:
>>>>>>> error:0A0C0103:SSL routines::internal error) while sending response to
>>>>>>> client, client: 192.168.80.130, server: win10-web-svr.dreamstone.com
>>>>>>> <http://win10-web-svr.dreamstone.com>, request: "GET /images/image001.jpg
>>>>>>> HTTP/1.1", host: "win10-web-svr.dreamstone.com
>>>>>>> <http://win10-web-svr.dreamstone.com>", referrer:
>>>>>>> "https://win10-web-svr.dreamstone.com/
>>>>>>> <https://win10-web-svr.dreamstone.com/>"*2023/02/23 21:24:49
>>>>>>> [debug] 4768#4528: *1 http write filter FFFFFFFFFFFFFFFF
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http copy filter: -1
>>>>>>> "/images/image001.jpg?"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http finalize request: -1,
>>>>>>> "/images/image001.jpg?" a:1, c:1
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate request
>>>>>>> count:1
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate cleanup
>>>>>>> count:1 blk:0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http posted request:
>>>>>>> "/images/image001.jpg?"
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate handler
>>>>>>> count:1
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http request count:1 blk:0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http close request
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http log handler
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 run cleanup:
>>>>>>> 000002DC83A7CBE8
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 file cleanup: fd:732
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A87340
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7BC00,
>>>>>>> unused: 0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7DC20,
>>>>>>> unused: 1167
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 close http connection: 500
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 select del event fd:500
>>>>>>> ev:768
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 reusable connection: 0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A647C0
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A8F350
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC8332EAB0,
>>>>>>> unused: 12
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7DA10,
>>>>>>> unused: 384
>>>>>>>
>>>>>>
>>>>>> On Thu, Feb 23, 2023 at 9:32 PM Dan Swaney <justdan23 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I tried to reproduce it with a simple web page and I'm seeing the
>>>>>>> issue which I believe you are having.
>>>>>>>
>>>>>>> By default, NGINX seems to default to some limit of 15k on responses
>>>>>>> of images returned directly.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>>
>>>>>>> I even tried to increase it by adding:
>>>>>>>
>>>>>>> location / {
>>>>>>>> root html;
>>>>>>>> index index.html index.htm favicon.ico;
>>>>>>>>
>>>>>>>> types {
>>>>>>>> text/html html;
>>>>>>>> image/gif gif;
>>>>>>>> application/octetstream jpg;
>>>>>>>> application/octetstream png;
>>>>>>>> }
>>>>>>>>
>>>>>>>> set $max_image_size 50000;
>>>>>>>> client_max_body_size 50000;
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 23, 2023 at 8:09 PM Dan Swaney <justdan23 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Try this:
>>>>>>>>
>>>>>>>> 1. At the very top of your nginx.conf file, add a definition:
>>>>>>>>
>>>>>>>> error_log logs/error.log debug;
>>>>>>>>
>>>>>>>> 2. Within your nginx install directory (where nginx.exe
>>>>>>>> exists), create a 'logs' folder if one does not exist.
>>>>>>>> 3. Restart nginx.exe (if running as a Windows Service with
>>>>>>>> NSSM, then restart the service).
>>>>>>>> 4. If NGINX does not start...
>>>>>>>> - Check the 'error.log' as it will tell you if your
>>>>>>>> nginx.conf has something weird in it that it doesn't like.
>>>>>>>> 5. If NGINX started successfully...
>>>>>>>> - Run your test from your client browser.
>>>>>>>> - Go back to the Server and check your 'error.log' and look
>>>>>>>> for the URL request.
>>>>>>>> - It will show you everything it does with routing or
>>>>>>>> looking for files.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 23, 2023 at 7:22 PM Saint Michael <venefax at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Now it remains broken and I have no idea how to fix it. I guess is
>>>>>>>>> caching bad copies of the pictures.
>>>>>>>>> I re-uploaded the two images.
>>>>>>>>> Kindly let me know if this is "normal"
>>>>>>>>> [image: image.png]
>>>>>>>>>
>>>>>>>>> On Thu, Feb 23, 2023 at 7:08 PM Dan Swaney <justdan23 at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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/92a3b1c0/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/92a3b1c0/attachment-0004.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/92a3b1c0/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 111869 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/92a3b1c0/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 193204 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/92a3b1c0/attachment-0007.png>
nginx -V
nginx version: openresty/1.21.4.1
built by gcc 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
built with OpenSSL 3.0.2 15 Mar 2022
TLS SNI support enabled
configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt=-O2
--add-module=../ngx_devel_kit-0.3.1 --add-module=../echo-nginx-module-0.62
--add-module=../xss-nginx-module-0.06 --add-module=../ngx_coolkit-0.2
--add-module=../set-misc-nginx-module-0.33
--add-module=../form-input-nginx-module-0.12
--add-module=../encrypted-session-nginx-module-0.09
--add-module=../srcache-nginx-module-0.32 --add-module=../ngx_lua-0.10.21
--add-module=../ngx_lua_upstream-0.07
--add-module=../headers-more-nginx-module-0.33
--add-module=../array-var-nginx-module-0.05
--add-module=../memc-nginx-module-0.19
--add-module=../redis2-nginx-module-0.15
--add-module=../redis-nginx-module-0.3.9
--add-module=../rds-json-nginx-module-0.15
--add-module=../rds-csv-nginx-module-0.09
--add-module=../ngx_stream_lua-0.0.11
--with-ld-opt=-Wl,-rpath,/usr/local/openresty/luajit/lib
--add-module=/usr/src/openresty-1.21.4.1/../ngx_http_substitutions_filter_module
--with-http_ssl_module --with-http_stub_status_module
--with-http_realip_module --with-stream --with-stream_ssl_module
--with-stream_ssl_preread_module
On Thu, Feb 23, 2023 at 10:43 PM Dan Swaney <justdan23 at gmail.com> wrote:
> Saint, can you also run 'nginx -V' and drop your build configuration here
> in this thread?
>
> On Thu, Feb 23, 2023 at 10:41 PM Dan Swaney <justdan23 at gmail.com> wrote:
>
>> To use HTTP2, you have to configure the build to include it. Same goes
>> for Kerberos GSSAPI SPNEGO Authentication support with the SPNEGO Module
>> for NGINX.
>>
>>
>>> nginx version: nginx/1.23.3
>>> built by cl 19.34.31937 for x64
>>> *built with OpenSSL 3.1.0-beta1-dev*
>>> TLS SNI support enabled
>>> configure arguments: --with-cc=cl --builddir=objs --with-debug
>>> --prefix=. --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
>>> --http-log-path=logs/access.log --error-log-path=logs/error.log
>>> --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp
>>> --http-proxy-temp-path=temp/proxy_temp
>>> --http-fastcgi-temp-path=temp/fastcgi_temp
>>> --http-scgi-temp-path=temp/scgi_temp --http-uwsgi-temp-path=temp/uwsgi_temp
>>> --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre2
>>> --with-zlib=objs/lib/zlib --with-select_module *--with-http_v2_module*
>>> --with-http_realip_module --with-http_addition_module
>>> --with-http_sub_module --with-http_dav_module
>>> --with-http_stub_status_module --with-http_flv_module
>>> --with-http_mp4_module --with-http_gunzip_module
>>> --with-http_gzip_static_module --with-http_auth_request_module
>>> --with-http_random_index_module --with-http_secure_link_module
>>> --with-http_slice_module --with-mail --with-stream --with-http_ssl_module
>>> --with-mail_ssl_module --with-stream_ssl_module
>>> --with-openssl=objs/lib/openssl
>>> --add-module=objs/lib/spnego-http-auth-nginx-module --with-cc-opt='-I
>>> objs/lib/krb5/objs/include'
>>>
>>
>>
>> On Thu, Feb 23, 2023 at 10:30 PM Saint Michael <venefax at gmail.com> wrote:
>>
>>> I enabled http2 but it fails
>>>
>>> nginx: [emerg] the "http2" parameter requires ngx_http_v2_module in
>>> /etc/federico/x3x.conf:17
>>>
>>> On Thu, Feb 23, 2023 at 10:25 PM Saint Michael <venefax at gmail.com>
>>> wrote:
>>>
>>>> can we add that at the top level? like a global value?
>>>>
>>>>
>>>> On Thu, Feb 23, 2023 at 10:17 PM Dan Swaney <justdan23 at gmail.com>
>>>> wrote:
>>>>
>>>>> See my earlier response above for details. It works when you reduce
>>>>> the ssl_buffer_size to 4k. You can try 8k for performance.
>>>>> (Correction: use the 'server' section for this setting.)
>>>>>
>>>>> server {
>>>>> ...
>>>>> ssl_buffer_size 4k;
>>>>> }
>>>>>
>>>>> Reference to setting is on this page:
>>>>>
>>>>> https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/
>>>>>
>>>>>
>>>>> The bug happens to be within the OpenSSL library I believe, but I
>>>>> found when reducing the buffer size to 4k, it worked for my test.
>>>>> There is a bug when it operates with the default of 16k and it fails
>>>>> to write out the response in 16k chunks, but does work with 4k chunks.
>>>>>
>>>>> On Thu, Feb 23, 2023 at 10:06 PM Saint Michael <venefax at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Please read this, it's from 2011/11/04, and it hasn't been fixed :
>>>>>>
>>>>>> https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 23, 2023 at 9:43 PM Dan Swaney <justdan23 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ah-ah...I caught the NGINX failure in the SSL response:
>>>>>>>
>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http filename:
>>>>>>>> "./html/images/image001.jpg"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 add cleanup:
>>>>>>>> 000002DC83A7CBE8
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http static fd: 732
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http set discard body
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map started
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 parse header: "Cookie:
>>>>>>>> SessionId SessionId="
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map started
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map: "" ""
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: ""
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http map: "" ""
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy:
>>>>>>>> "SessionId SessionId="
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var: ""
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy:
>>>>>>>> ";AuthId="
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var:
>>>>>>>> "SessionId SessionId="
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: "
>>>>>>>> SessionId="
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script var:
>>>>>>>> "ab3e389a16b819b5477309665cfcc4672f47d5657e1c154381c6eb8336963721"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http script copy: ";
>>>>>>>> Domain=win10-web-svr.dreamstone.com; Path=/; HttpOnly; Secure"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 HTTP/1.1 200 OK
>>>>>>>> Server: nginx/1.23.3
>>>>>>>> Date: Fri, 24 Feb 2023 02:24:49 GMT
>>>>>>>> Content-Type: application/octetstream
>>>>>>>> *Content-Length: 123197*
>>>>>>>> Last-Modified: Wed, 30 Nov 2022 19:41:21 GMT
>>>>>>>> Connection: keep-alive
>>>>>>>> ETag: "6387b1e1-1e13d"
>>>>>>>> Strict-Transport-Security: max-age=15768000; preload
>>>>>>>> X-Frame-Options: SAMEORIGIN
>>>>>>>> X-XSS-Protection: 1
>>>>>>>> X-Content-Type-Options: nosniff
>>>>>>>> Referred-Policy: strict-origin
>>>>>>>> Set-Cookie: SessionId SessionId=;AuthId=SessionId SessionId=
>>>>>>>> SessionId=ab3e389a16b819b5477309665cfcc4672f47d5657e1c154381c6eb8336963721;
>>>>>>>> Domain=win10-web-svr.dreamstone.com; Path=/; HttpOnly; Secure
>>>>>>>> Accept-Ranges: bytes
>>>>>>>>
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write new buf t:1 f:0
>>>>>>>> 000002DC83A7E2F0, pos 000002DC83A7E2F0, size: 626 file: 0, size: 0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter: l:0
>>>>>>>> f:0 s:626
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http output filter
>>>>>>>> "/images/image001.jpg?"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http copy filter:
>>>>>>>> "/images/image001.jpg?"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 malloc:
>>>>>>>> 000002DC83A87340:32768
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http postpone filter
>>>>>>>> "/images/image001.jpg?" 000002DC83A7E658
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write old buf t:1 f:0
>>>>>>>> 000002DC83A7E2F0, pos 000002DC83A7E2F0, size: 626 file: 0, size: 0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 write new buf t:1 f:0
>>>>>>>> 000002DC83A87340, pos 000002DC83A87340, size: 32768 file: 0, size: 0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter: l:0
>>>>>>>> f:1 s:33394
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http write filter limit
>>>>>>>> 2097152
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 malloc:
>>>>>>>> 000002DC83A8F350:16384
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL buf copy: 626
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL buf copy: 15758
>>>>>>>> *2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL to write: 16384*
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: ssl remove session:
>>>>>>>> B87DD7B9:32
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: shmtx lock
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: shmtx unlock
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL_write: -1
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 SSL_get_error: 1
>>>>>>>>
>>>>>>>> *2023/02/23 21:24:49 [crit] 4768#4528: *1 SSL_write() failed (SSL:
>>>>>>>> error:0A0C0103:SSL routines::internal error) while sending response to
>>>>>>>> client, client: 192.168.80.130, server: win10-web-svr.dreamstone.com
>>>>>>>> <http://win10-web-svr.dreamstone.com>, request: "GET /images/image001.jpg
>>>>>>>> HTTP/1.1", host: "win10-web-svr.dreamstone.com
>>>>>>>> <http://win10-web-svr.dreamstone.com>", referrer:
>>>>>>>> "https://win10-web-svr.dreamstone.com/
>>>>>>>> <https://win10-web-svr.dreamstone.com/>"*2023/02/23 21:24:49
>>>>>>>> [debug] 4768#4528: *1 http write filter FFFFFFFFFFFFFFFF
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http copy filter: -1
>>>>>>>> "/images/image001.jpg?"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http finalize request:
>>>>>>>> -1, "/images/image001.jpg?" a:1, c:1
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate request
>>>>>>>> count:1
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate cleanup
>>>>>>>> count:1 blk:0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http posted request:
>>>>>>>> "/images/image001.jpg?"
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http terminate handler
>>>>>>>> count:1
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http request count:1 blk:0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http close request
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 http log handler
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 run cleanup:
>>>>>>>> 000002DC83A7CBE8
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 file cleanup: fd:732
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A87340
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7BC00,
>>>>>>>> unused: 0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7DC20,
>>>>>>>> unused: 1167
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 close http connection: 500
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 select del event fd:500
>>>>>>>> ev:768
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 reusable connection: 0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A647C0
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A8F350
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC8332EAB0,
>>>>>>>> unused: 12
>>>>>>>> 2023/02/23 21:24:49 [debug] 4768#4528: *1 free: 000002DC83A7DA10,
>>>>>>>> unused: 384
>>>>>>>>
>>>>>>>
>>>>>>> On Thu, Feb 23, 2023 at 9:32 PM Dan Swaney <justdan23 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I tried to reproduce it with a simple web page and I'm seeing the
>>>>>>>> issue which I believe you are having.
>>>>>>>>
>>>>>>>> By default, NGINX seems to default to some limit of 15k on
>>>>>>>> responses of images returned directly.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>>
>>>>>>>> I even tried to increase it by adding:
>>>>>>>>
>>>>>>>> location / {
>>>>>>>>> root html;
>>>>>>>>> index index.html index.htm favicon.ico;
>>>>>>>>>
>>>>>>>>> types {
>>>>>>>>> text/html html;
>>>>>>>>> image/gif gif;
>>>>>>>>> application/octetstream jpg;
>>>>>>>>> application/octetstream png;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> set $max_image_size 50000;
>>>>>>>>> client_max_body_size 50000;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Feb 23, 2023 at 8:09 PM Dan Swaney <justdan23 at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Try this:
>>>>>>>>>
>>>>>>>>> 1. At the very top of your nginx.conf file, add a definition:
>>>>>>>>>
>>>>>>>>> error_log logs/error.log debug;
>>>>>>>>>
>>>>>>>>> 2. Within your nginx install directory (where nginx.exe
>>>>>>>>> exists), create a 'logs' folder if one does not exist.
>>>>>>>>> 3. Restart nginx.exe (if running as a Windows Service with
>>>>>>>>> NSSM, then restart the service).
>>>>>>>>> 4. If NGINX does not start...
>>>>>>>>> - Check the 'error.log' as it will tell you if your
>>>>>>>>> nginx.conf has something weird in it that it doesn't like.
>>>>>>>>> 5. If NGINX started successfully...
>>>>>>>>> - Run your test from your client browser.
>>>>>>>>> - Go back to the Server and check your 'error.log' and look
>>>>>>>>> for the URL request.
>>>>>>>>> - It will show you everything it does with routing or
>>>>>>>>> looking for files.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Feb 23, 2023 at 7:22 PM Saint Michael <venefax at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Now it remains broken and I have no idea how to fix it. I guess
>>>>>>>>>> is caching bad copies of the pictures.
>>>>>>>>>> I re-uploaded the two images.
>>>>>>>>>> Kindly let me know if this is "normal"
>>>>>>>>>> [image: image.png]
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 23, 2023 at 7:08 PM Dan Swaney <justdan23 at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>> _______________________________________________
> 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/b08dde26/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/b08dde26/attachment-0004.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/b08dde26/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 111869 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/b08dde26/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 193204 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/b08dde26/attachment-0007.png>
Hello!
On Thu, Feb 23, 2023 at 10:35:16PM -0500, Dan Swaney wrote:
> Hi Maxim,
>
> Here is the version details from my full recompile of NGINX 64-bit on
> Windows. My code base is 2 months old, but it reproduced Saint's issue.
>
> nginx version: nginx/1.23.3
> > built by cl 19.34.31937 for x64
> > *built with OpenSSL 3.1.0-beta1-dev*
> > TLS SNI support enabled
> > configure arguments: --with-cc=cl --builddir=objs --with-debug --prefix=.
> > --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
> > --http-log-path=logs/access.log --error-log-path=logs/error.log
> > --sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp
> > --http-proxy-temp-path=temp/proxy_temp
> > --http-fastcgi-temp-path=temp/fastcgi_temp
> > --http-scgi-temp-path=temp/scgi_temp --http-uwsgi-temp-path=temp/uwsgi_temp
> > --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre2
> > --with-zlib=objs/lib/zlib --with-select_module --with-http_v2_module
> > --with-http_realip_module --with-http_addition_module
> > --with-http_sub_module --with-http_dav_module
> > --with-http_stub_status_module --with-http_flv_module
> > --with-http_mp4_module --with-http_gunzip_module
> > --with-http_gzip_static_module --with-http_auth_request_module
> > --with-http_random_index_module --with-http_secure_link_module
> > --with-http_slice_module --with-mail --with-stream --with-http_ssl_module
> > --with-mail_ssl_module --with-stream_ssl_module
> > --with-openssl=objs/lib/openssl
> > --add-module=objs/lib/spnego-http-auth-nginx-module --with-cc-opt='-I
> > objs/lib/krb5/objs/include'
> >
>
> I'm using a OpenSSL beta build from earlier, but I was able to reproduce
Thanks for the details, OpenSSL 3.1.0-beta1 perfectly explains the
issue you are seeing. Avoid using it for anything but testing
OpenSSL itself.
> Saint's issue and discovered the work-around with lowering the
> ssl_buffer_size to 4k, Something for Saint to try out.
I don't think it's related. The issue you are seeing is very
specific to some broken OpenSSL development builds, and shouldn't
appear anywhere else.
--
Maxim Dounin
http://mdounin.ru/
So what do you think causes my issue with the images?
I in fact removed any likes in location /{} and it seems stable.
which negs the question, if I have 10 HTML files, which on will be served
by default?
nginx version: openresty/1.21.4.1
built by gcc 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
built with OpenSSL 3.0.2 15 Mar 2022
On Thu, Feb 23, 2023 at 11:13 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Thu, Feb 23, 2023 at 10:35:16PM -0500, Dan Swaney wrote:
>
> > Hi Maxim,
> >
> > Here is the version details from my full recompile of NGINX 64-bit on
> > Windows. My code base is 2 months old, but it reproduced Saint's issue.
> >
> > nginx version: nginx/1.23.3
> > > built by cl 19.34.31937 for x64
> > > *built with OpenSSL 3.1.0-beta1-dev*
> > > TLS SNI support enabled
> > > configure arguments: --with-cc=cl --builddir=objs --with-debug
> --prefix=.
> > > --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
> > > --http-log-path=logs/access.log --error-log-path=logs/error.log
> > > --sbin-path=nginx.exe
> --http-client-body-temp-path=temp/client_body_temp
> > > --http-proxy-temp-path=temp/proxy_temp
> > > --http-fastcgi-temp-path=temp/fastcgi_temp
> > > --http-scgi-temp-path=temp/scgi_temp
> --http-uwsgi-temp-path=temp/uwsgi_temp
> > > --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre2
> > > --with-zlib=objs/lib/zlib --with-select_module --with-http_v2_module
> > > --with-http_realip_module --with-http_addition_module
> > > --with-http_sub_module --with-http_dav_module
> > > --with-http_stub_status_module --with-http_flv_module
> > > --with-http_mp4_module --with-http_gunzip_module
> > > --with-http_gzip_static_module --with-http_auth_request_module
> > > --with-http_random_index_module --with-http_secure_link_module
> > > --with-http_slice_module --with-mail --with-stream
> --with-http_ssl_module
> > > --with-mail_ssl_module --with-stream_ssl_module
> > > --with-openssl=objs/lib/openssl
> > > --add-module=objs/lib/spnego-http-auth-nginx-module --with-cc-opt='-I
> > > objs/lib/krb5/objs/include'
> > >
> >
> > I'm using a OpenSSL beta build from earlier, but I was able to reproduce
>
> Thanks for the details, OpenSSL 3.1.0-beta1 perfectly explains the
> issue you are seeing. Avoid using it for anything but testing
> OpenSSL itself.
>
> > Saint's issue and discovered the work-around with lowering the
> > ssl_buffer_size to 4k, Something for Saint to try out.
>
> I don't think it's related. The issue you are seeing is very
> specific to some broken OpenSSL development builds, and shouldn't
> appear anywhere else.
>
> --
> 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/20230223/cd65ed89/attachment.htm>
Now my website downloads the text instead of delivering website/
https://1eye.us/
what did mess up?
On Thu, Feb 23, 2023 at 11:26 PM Saint Michael <venefax at gmail.com> wrote:
> So what do you think causes my issue with the images?
> I in fact removed any likes in location /{} and it seems stable.
> which negs the question, if I have 10 HTML files, which on will be served
> by default?
>
> nginx version: openresty/1.21.4.1
> built by gcc 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04)
> built with OpenSSL 3.0.2 15 Mar 2022
>
> On Thu, Feb 23, 2023 at 11:13 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Thu, Feb 23, 2023 at 10:35:16PM -0500, Dan Swaney wrote:
>>
>> > Hi Maxim,
>> >
>> > Here is the version details from my full recompile of NGINX 64-bit on
>> > Windows. My code base is 2 months old, but it reproduced Saint's issue.
>> >
>> > nginx version: nginx/1.23.3
>> > > built by cl 19.34.31937 for x64
>> > > *built with OpenSSL 3.1.0-beta1-dev*
>> > > TLS SNI support enabled
>> > > configure arguments: --with-cc=cl --builddir=objs --with-debug
>> --prefix=.
>> > > --conf-path=conf/nginx.conf --pid-path=logs/nginx.pid
>> > > --http-log-path=logs/access.log --error-log-path=logs/error.log
>> > > --sbin-path=nginx.exe
>> --http-client-body-temp-path=temp/client_body_temp
>> > > --http-proxy-temp-path=temp/proxy_temp
>> > > --http-fastcgi-temp-path=temp/fastcgi_temp
>> > > --http-scgi-temp-path=temp/scgi_temp
>> --http-uwsgi-temp-path=temp/uwsgi_temp
>> > > --with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre2
>> > > --with-zlib=objs/lib/zlib --with-select_module --with-http_v2_module
>> > > --with-http_realip_module --with-http_addition_module
>> > > --with-http_sub_module --with-http_dav_module
>> > > --with-http_stub_status_module --with-http_flv_module
>> > > --with-http_mp4_module --with-http_gunzip_module
>> > > --with-http_gzip_static_module --with-http_auth_request_module
>> > > --with-http_random_index_module --with-http_secure_link_module
>> > > --with-http_slice_module --with-mail --with-stream
>> --with-http_ssl_module
>> > > --with-mail_ssl_module --with-stream_ssl_module
>> > > --with-openssl=objs/lib/openssl
>> > > --add-module=objs/lib/spnego-http-auth-nginx-module --with-cc-opt='-I
>> > > objs/lib/krb5/objs/include'
>> > >
>> >
>> > I'm using a OpenSSL beta build from earlier, but I was able to reproduce
>>
>> Thanks for the details, OpenSSL 3.1.0-beta1 perfectly explains the
>> issue you are seeing. Avoid using it for anything but testing
>> OpenSSL itself.
>>
>> > Saint's issue and discovered the work-around with lowering the
>> > ssl_buffer_size to 4k, Something for Saint to try out.
>>
>> I don't think it's related. The issue you are seeing is very
>> specific to some broken OpenSSL development builds, and shouldn't
>> appear anywhere else.
>>
>> --
>> 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/20230223/e662677a/attachment.htm>