From bmvishwas at gmail.com  Thu Feb  2 07:33:13 2023
From: bmvishwas at gmail.com (Vishwas Bm)
Date: Thu, 2 Feb 2023 13:03:13 +0530
Subject: Use of upstream keepalive_time
In-Reply-To: <Y8srgmn4ohyUToEN@mdounin.ru>
References: <CANgk=80bOnUUcv5hxrypf=+3mJ9xLGjQuWgLsxTLL-RLoZ_AKw@mail.gmail.com>
 <Y8srgmn4ohyUToEN@mdounin.ru>
Message-ID: <CANgk=817tQ8rJRyofgoBbr40JNe=Ex5KxbDaJxiSnsQXafenVg@mail.gmail.com>

Thanks for the reply.

Can this keepalive_time be made infinite ?
So that connection is not broken after default 1hr


Regards,
Vishwas


On Sat, Jan 21, 2023, 05:32 Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Fri, Jan 20, 2023 at 11:37:15AM +0530, Vishwas Bm wrote:
>
> > I see that from 1.19.10 keepalive_time has been added.
> >
> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_time
> >
> > Also keepalive_timeout is present for idle connection
> >
> http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive_timeout
> >
> > On checking the behaviour between these two, I see that keepalive_time is
> > having higher precedence over keepalive_timeout.
> > Even if connection is not idle based on keepqlive_timeout, connection is
> > still  getting closed because of keepalive_time.
> >
> > Is this expected behaviour?
> > Also can I set keepalive_time to higher value say 24hours ? Any drawbacks
> > with this ?
> > Can this keepalive_time be disabled and priority given only to
> > keepalive_timeout ?
>
> The "keepalive_time" is a directive to limit total lifetime of the
> connection, making it possible to free any resources associated
> with the connection, notably allocated memory.  Further, in some
> setups it might be important to periodically redo connection
> authentication, notably re-validate peer certificates.
>
> The "keepalive_time" directive is mostly equivalent to
> keepalive_requests, which is documented as follows:
>
> : Closing connections periodically is necessary to free
> : per-connection memory allocations. Therefore, using too high
> : maximum number of requests could result in excessive memory usage
> : and not recommended.
>
> Note though that keepalive_time is 1 hour by default, and reopening
> connections once per hour is not expected to have any performance
> impact.  Rather, it is expected to be a hard limit on the total
> connection lifetime on connections which are mostly idle and
> therefore do not reach the "keepalive_requests" limit in a
> reasonable time.
>
> --
> 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/20230202/088ac339/attachment.htm>

From mdounin at mdounin.ru  Fri Feb  3 03:16:33 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 3 Feb 2023 06:16:33 +0300
Subject: Use of upstream keepalive_time
In-Reply-To: <CANgk=817tQ8rJRyofgoBbr40JNe=Ex5KxbDaJxiSnsQXafenVg@mail.gmail.com>
References: <CANgk=80bOnUUcv5hxrypf=+3mJ9xLGjQuWgLsxTLL-RLoZ_AKw@mail.gmail.com>
 <Y8srgmn4ohyUToEN@mdounin.ru>
 <CANgk=817tQ8rJRyofgoBbr40JNe=Ex5KxbDaJxiSnsQXafenVg@mail.gmail.com>
Message-ID: <Y9x8kRPohCFrrKSi@mdounin.ru>

Hello!

On Thu, Feb 02, 2023 at 01:03:13PM +0530, Vishwas Bm wrote:

> Can this keepalive_time be made infinite ?
> So that connection is not broken after default 1hr

There is no specific infinite value, though you can use a large 
enough keepalive_time instead.  Something like "keepalive_time 10d;" 
should be a good replacement for "infinite".

Note though that this might not be a good idea for the reasons 
outlined in the previous response.

[...]

> > The "keepalive_time" is a directive to limit total lifetime of the
> > connection, making it possible to free any resources associated
> > with the connection, notably allocated memory.  Further, in some
> > setups it might be important to periodically redo connection
> > authentication, notably re-validate peer certificates.
> >
> > The "keepalive_time" directive is mostly equivalent to
> > keepalive_requests, which is documented as follows:
> >
> > : Closing connections periodically is necessary to free
> > : per-connection memory allocations. Therefore, using too high
> > : maximum number of requests could result in excessive memory usage
> > : and not recommended.
> >
> > Note though that keepalive_time is 1 hour by default, and reopening
> > connections once per hour is not expected to have any performance
> > impact.  Rather, it is expected to be a hard limit on the total
> > connection lifetime on connections which are mostly idle and
> > therefore do not reach the "keepalive_requests" limit in a
> > reasonable time.

-- 
Maxim Dounin
http://mdounin.ru/

From venefax at gmail.com  Fri Feb  3 06:56:51 2023
From: venefax at gmail.com (Saint Michael)
Date: Fri, 3 Feb 2023 01:56:51 -0500
Subject: Help beating cloudflare
Message-ID: <CAC9cSOA_2YdJ7hrjFj-fc4LQDLVhDjDNJ8eM_0a2xZu-wrdN1g@mail.gmail.com>

I have a reverse proxy but the newspaper that  I am proxying is
protected by cloudflare, and the block me immediately, even if I use a
different IP. So somehow they know how to identify my reverse-proxy.
How is my request different than a regular browser? What is giving me up?
can somebody give an example of what are the rules so my proxy passes
for a regular person?
This is what I do now

location / {
proxy_cookie_domain https://www.xxx.com/ https://xxx.xxye.us;
proxy_set_header Host www.xxx.com;
proxy_pass https://www.xxx.com;
proxy_redirect https://www.xxx.com https://xxx.xxye.us;
 proxy_buffering on;
resolver 127.0.0.1 ipv6=off;
proxy_http_version 1.1;
proxy_buffer_size  128k;
proxy_busy_buffers_size  256k;
proxy_buffers 4 256k;
proxy_set_header User-Agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82
Safari/537.36";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_set_header Accept-Encoding "";
proxy_ssl_server_name on;
proxy_ssl_name $proxy_host;
}

From lukas at ltri.eu  Fri Feb  3 07:54:05 2023
From: lukas at ltri.eu (Lukas Tribus)
Date: Fri, 3 Feb 2023 08:54:05 +0100
Subject: Help beating cloudflare
In-Reply-To: <CAC9cSOA_2YdJ7hrjFj-fc4LQDLVhDjDNJ8eM_0a2xZu-wrdN1g@mail.gmail.com>
References: <CAC9cSOA_2YdJ7hrjFj-fc4LQDLVhDjDNJ8eM_0a2xZu-wrdN1g@mail.gmail.com>
Message-ID: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>

On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:

> I have a reverse proxy but the newspaper that  I am proxying is
> protected by cloudflare, and the block me immediately, even if I use a
> different IP. So somehow they know how to identify my reverse-proxy.
> How is my request different than a regular browser? What is giving me up?
> can somebody give an example of what are the rules so my proxy passes
> for a regular person?


>
OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.

You will not beat Cloudflare anti bot functionality with a few nginx
settings... this is a rabbit hole.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230203/3356bce4/attachment.htm>

From manuel.baesler at gmail.com  Fri Feb  3 09:39:00 2023
From: manuel.baesler at gmail.com (Manuel)
Date: Fri, 3 Feb 2023 10:39:00 +0100
Subject: Help beating cloudflare
In-Reply-To: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
References: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
Message-ID: <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>

Hi,

do you forward all headers the browser sends to the server?
The chrome version is very old.
You need to pretend that you are the browser.

Kind regards,
Manuel




> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
> 
> 
> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>> I have a reverse proxy but the newspaper that  I am proxying is
>> protected by cloudflare, and the block me immediately, even if I use a
>> different IP. So somehow they know how to identify my reverse-proxy.
>> How is my request different than a regular browser? What is giving me up?
>> can somebody give an example of what are the rules so my proxy passes
>> for a regular person?
> 
> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
> 
> You will not beat Cloudflare anti bot functionality with a few nginx settings... this is a rabbit hole.
> 
> 
> 
> 
> _______________________________________________
> 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/20230203/82819aa5/attachment.htm>

From venefax at gmail.com  Fri Feb  3 11:56:41 2023
From: venefax at gmail.com (Saint Michael)
Date: Fri, 3 Feb 2023 06:56:41 -0500
Subject: Help beating cloudflare
In-Reply-To: <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>
References: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
 <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>
Message-ID: <CAC9cSOBL_TCz4fGY6hKjsy6a_o3SOrNARUDkpvz75nVO-inB5w@mail.gmail.com>

I am sure that it can be done. I am just passing everything to them.

On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:

> Hi,
>
> do you forward all headers the browser sends to the server?
> The chrome version is very old.
> You need to pretend that you are the browser.
>
> Kind regards,
> Manuel
>
>
>
>
> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>
> 
>
> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>
>> I have a reverse proxy but the newspaper that  I am proxying is
>> protected by cloudflare, and the block me immediately, even if I use a
>> different IP. So somehow they know how to identify my reverse-proxy.
>> How is my request different than a regular browser? What is giving me up?
>> can somebody give an example of what are the rules so my proxy passes
>> for a regular person?
>
>
>>
> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>
> You will not beat Cloudflare anti bot functionality with a few nginx
> settings... this is a rabbit hole.
>
>
>
>
> _______________________________________________
> 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/20230203/78978327/attachment.htm>

From pchychi at gmail.com  Fri Feb  3 16:21:54 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Fri, 3 Feb 2023 08:21:54 -0800
Subject: Help beating cloudflare
In-Reply-To: <CAC9cSOBL_TCz4fGY6hKjsy6a_o3SOrNARUDkpvz75nVO-inB5w@mail.gmail.com>
References: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
 <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>
 <CAC9cSOBL_TCz4fGY6hKjsy6a_o3SOrNARUDkpvz75nVO-inB5w@mail.gmail.com>
Message-ID: <CAJMkcM28j_DXv6o=Si-8RJoYSzeeL02Nzj_9PRi0CUkba_CRyQ@mail.gmail.com>

Lol, that is the point…. Proxies do stuff to the connection that makes it
easy to detect if you know what you are looking for :)

As it stands… you are not going to win this one.


On Fri, Feb 3, 2023 at 3:57 AM Saint Michael <venefax at gmail.com> wrote:

> I am sure that it can be done. I am just passing everything to them.
>
> On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:
>
>> Hi,
>>
>> do you forward all headers the browser sends to the server?
>> The chrome version is very old.
>> You need to pretend that you are the browser.
>>
>> Kind regards,
>> Manuel
>>
>>
>>
>>
>> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>>
>> 
>>
>> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>>
>>> I have a reverse proxy but the newspaper that  I am proxying is
>>> protected by cloudflare, and the block me immediately, even if I use a
>>> different IP. So somehow they know how to identify my reverse-proxy.
>>> How is my request different than a regular browser? What is giving me up?
>>> can somebody give an example of what are the rules so my proxy passes
>>> for a regular person?
>>
>>
>>>
>> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>>
>> You will not beat Cloudflare anti bot functionality with a few nginx
>> settings... this is a rabbit hole.
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230203/01c7fd19/attachment.htm>

From venefax at gmail.com  Fri Feb  3 17:14:22 2023
From: venefax at gmail.com (Saint Michael)
Date: Fri, 3 Feb 2023 12:14:22 -0500
Subject: Help beating cloudflare
In-Reply-To: <CAJMkcM28j_DXv6o=Si-8RJoYSzeeL02Nzj_9PRi0CUkba_CRyQ@mail.gmail.com>
References: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
 <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>
 <CAC9cSOBL_TCz4fGY6hKjsy6a_o3SOrNARUDkpvz75nVO-inB5w@mail.gmail.com>
 <CAJMkcM28j_DXv6o=Si-8RJoYSzeeL02Nzj_9PRi0CUkba_CRyQ@mail.gmail.com>
Message-ID: <CAC9cSOCk+OwL8N5sP7_wbGuV4d5tuxE98ajwmVu-1aG9ktkvTQ@mail.gmail.com>

I won already.
Thanks to chatgpt.
I asked the question and it gave the answer.

On Fri, Feb 3, 2023, 11:22 AM Payam Chychi <pchychi at gmail.com> wrote:

> Lol, that is the point…. Proxies do stuff to the connection that makes it
> easy to detect if you know what you are looking for :)
>
> As it stands… you are not going to win this one.
>
>
> On Fri, Feb 3, 2023 at 3:57 AM Saint Michael <venefax at gmail.com> wrote:
>
>> I am sure that it can be done. I am just passing everything to them.
>>
>> On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> do you forward all headers the browser sends to the server?
>>> The chrome version is very old.
>>> You need to pretend that you are the browser.
>>>
>>> Kind regards,
>>> Manuel
>>>
>>>
>>>
>>>
>>> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>>>
>>> 
>>>
>>> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>>>
>>>> I have a reverse proxy but the newspaper that  I am proxying is
>>>> protected by cloudflare, and the block me immediately, even if I use a
>>>> different IP. So somehow they know how to identify my reverse-proxy.
>>>> How is my request different than a regular browser? What is giving me
>>>> up?
>>>> can somebody give an example of what are the rules so my proxy passes
>>>> for a regular person?
>>>
>>>
>>>>
>>> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>>>
>>> You will not beat Cloudflare anti bot functionality with a few nginx
>>> settings... this is a rabbit hole.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230203/ee844cf8/attachment.htm>

From pchychi at gmail.com  Fri Feb  3 17:53:12 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Fri, 3 Feb 2023 09:53:12 -0800
Subject: Help beating cloudflare
In-Reply-To: <CAC9cSOCk+OwL8N5sP7_wbGuV4d5tuxE98ajwmVu-1aG9ktkvTQ@mail.gmail.com>
References: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
 <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>
 <CAC9cSOBL_TCz4fGY6hKjsy6a_o3SOrNARUDkpvz75nVO-inB5w@mail.gmail.com>
 <CAJMkcM28j_DXv6o=Si-8RJoYSzeeL02Nzj_9PRi0CUkba_CRyQ@mail.gmail.com>
 <CAC9cSOCk+OwL8N5sP7_wbGuV4d5tuxE98ajwmVu-1aG9ktkvTQ@mail.gmail.com>
Message-ID: <CAJMkcM1NF0tZL6AhwgBcmE+QPWrhKRqq9AXsj3PxjPg+1pCN=g@mail.gmail.com>

Nice job! Though I think what you mean is that you found the answer by
searching, chatgpt or otherwise :)

Keep in mind, chatgpt is trained on 2y old data :)

On Fri, Feb 3, 2023 at 9:14 AM Saint Michael <venefax at gmail.com> wrote:

> I won already.
> Thanks to chatgpt.
> I asked the question and it gave the answer.
>
> On Fri, Feb 3, 2023, 11:22 AM Payam Chychi <pchychi at gmail.com> wrote:
>
>> Lol, that is the point…. Proxies do stuff to the connection that makes it
>> easy to detect if you know what you are looking for :)
>>
>> As it stands… you are not going to win this one.
>>
>>
>> On Fri, Feb 3, 2023 at 3:57 AM Saint Michael <venefax at gmail.com> wrote:
>>
>>> I am sure that it can be done. I am just passing everything to them.
>>>
>>> On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> do you forward all headers the browser sends to the server?
>>>> The chrome version is very old.
>>>> You need to pretend that you are the browser.
>>>>
>>>> Kind regards,
>>>> Manuel
>>>>
>>>>
>>>>
>>>>
>>>> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>>>>
>>>> 
>>>>
>>>> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>>>>
>>>>> I have a reverse proxy but the newspaper that  I am proxying is
>>>>> protected by cloudflare, and the block me immediately, even if I use a
>>>>> different IP. So somehow they know how to identify my reverse-proxy.
>>>>> How is my request different than a regular browser? What is giving me
>>>>> up?
>>>>> can somebody give an example of what are the rules so my proxy passes
>>>>> for a regular person?
>>>>
>>>>
>>>>>
>>>> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>>>>
>>>> You will not beat Cloudflare anti bot functionality with a few nginx
>>>> settings... this is a rabbit hole.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> --
>> Payam Tarverdyan Chychi
>> _______________________________________________
>> 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
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230203/a1f4c59d/attachment-0001.htm>

From venefax at gmail.com  Fri Feb  3 18:45:54 2023
From: venefax at gmail.com (Saint Michael)
Date: Fri, 3 Feb 2023 13:45:54 -0500
Subject: Help beating cloudflare
In-Reply-To: <CAJMkcM1NF0tZL6AhwgBcmE+QPWrhKRqq9AXsj3PxjPg+1pCN=g@mail.gmail.com>
References: <CACC_My9kSZtB0xGtoNgVCxqpK0Y=pkmCYtCrU32Z4Jm0EtC7LA@mail.gmail.com>
 <CEF486E5-BF64-4F36-BA2C-3561DA09A5C7@gmail.com>
 <CAC9cSOBL_TCz4fGY6hKjsy6a_o3SOrNARUDkpvz75nVO-inB5w@mail.gmail.com>
 <CAJMkcM28j_DXv6o=Si-8RJoYSzeeL02Nzj_9PRi0CUkba_CRyQ@mail.gmail.com>
 <CAC9cSOCk+OwL8N5sP7_wbGuV4d5tuxE98ajwmVu-1aG9ktkvTQ@mail.gmail.com>
 <CAJMkcM1NF0tZL6AhwgBcmE+QPWrhKRqq9AXsj3PxjPg+1pCN=g@mail.gmail.com>
Message-ID: <CAC9cSODT5Xg8CxRG-4hCwkEWLStTGJqR6fBhhnTLa9BQEpNT7Q@mail.gmail.com>

Yes
2 years ago nginx was very popular.

Federico

On Fri, Feb 3, 2023, 12:53 PM Payam Chychi <pchychi at gmail.com> wrote:

> Nice job! Though I think what you mean is that you found the answer by
> searching, chatgpt or otherwise :)
>
> Keep in mind, chatgpt is trained on 2y old data :)
>
> On Fri, Feb 3, 2023 at 9:14 AM Saint Michael <venefax at gmail.com> wrote:
>
>> I won already.
>> Thanks to chatgpt.
>> I asked the question and it gave the answer.
>>
>> On Fri, Feb 3, 2023, 11:22 AM Payam Chychi <pchychi at gmail.com> wrote:
>>
>>> Lol, that is the point…. Proxies do stuff to the connection that makes
>>> it easy to detect if you know what you are looking for :)
>>>
>>> As it stands… you are not going to win this one.
>>>
>>>
>>> On Fri, Feb 3, 2023 at 3:57 AM Saint Michael <venefax at gmail.com> wrote:
>>>
>>>> I am sure that it can be done. I am just passing everything to them.
>>>>
>>>> On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> do you forward all headers the browser sends to the server?
>>>>> The chrome version is very old.
>>>>> You need to pretend that you are the browser.
>>>>>
>>>>> Kind regards,
>>>>> Manuel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>>>>>
>>>>> 
>>>>>
>>>>> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>>>>>
>>>>>> I have a reverse proxy but the newspaper that  I am proxying is
>>>>>> protected by cloudflare, and the block me immediately, even if I use a
>>>>>> different IP. So somehow they know how to identify my reverse-proxy.
>>>>>> How is my request different than a regular browser? What is giving me
>>>>>> up?
>>>>>> can somebody give an example of what are the rules so my proxy passes
>>>>>> for a regular person?
>>>>>
>>>>>
>>>>>>
>>>>> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>>>>>
>>>>> You will not beat Cloudflare anti bot functionality with a few nginx
>>>>> settings... this is a rabbit hole.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> --
>>> Payam Tarverdyan Chychi
>>> _______________________________________________
>>> 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
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230203/311f93b8/attachment.htm>

From manuel.baesler at gmail.com  Fri Feb  3 21:00:20 2023
From: manuel.baesler at gmail.com (Manuel)
Date: Fri, 3 Feb 2023 22:00:20 +0100
Subject: Help beating cloudflare
In-Reply-To: <CAC9cSODT5Xg8CxRG-4hCwkEWLStTGJqR6fBhhnTLa9BQEpNT7Q@mail.gmail.com>
References: <CAC9cSODT5Xg8CxRG-4hCwkEWLStTGJqR6fBhhnTLa9BQEpNT7Q@mail.gmail.com>
Message-ID: <854D013F-A745-477D-8A9F-7C522760744A@gmail.com>

How cool is that.

Now I am curious: what was the solution? :-)

> Am 03.02.2023 um 19:46 schrieb Saint Michael <venefax at gmail.com>:
> 
> 
> Yes
> 2 years ago nginx was very popular.
> 
> Federico
> 
>> On Fri, Feb 3, 2023, 12:53 PM Payam Chychi <pchychi at gmail.com> wrote:
>> Nice job! Though I think what you mean is that you found the answer by searching, chatgpt or otherwise :)
>> 
>> Keep in mind, chatgpt is trained on 2y old data :)
>> 
>>> On Fri, Feb 3, 2023 at 9:14 AM Saint Michael <venefax at gmail.com> wrote:
>>> I won already.
>>> Thanks to chatgpt.
>>> I asked the question and it gave the answer.
>>> 
>>>> On Fri, Feb 3, 2023, 11:22 AM Payam Chychi <pchychi at gmail.com> wrote:
>>>> Lol, that is the point…. Proxies do stuff to the connection that makes it easy to detect if you know what you are looking for :)
>>>> 
>>>> As it stands… you are not going to win this one.
>>>> 
>>>> 
>>>>> On Fri, Feb 3, 2023 at 3:57 AM Saint Michael <venefax at gmail.com> wrote:
>>>>> I am sure that it can be done. I am just passing everything to them.
>>>>> 
>>>>>> On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> do you forward all headers the browser sends to the server?
>>>>>> The chrome version is very old.
>>>>>> You need to pretend that you are the browser.
>>>>>> 
>>>>>> Kind regards,
>>>>>> Manuel
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>>>>>>>> I have a reverse proxy but the newspaper that  I am proxying is
>>>>>>>> protected by cloudflare, and the block me immediately, even if I use a
>>>>>>>> different IP. So somehow they know how to identify my reverse-proxy.
>>>>>>>> How is my request different than a regular browser? What is giving me up?
>>>>>>>> can somebody give an example of what are the rules so my proxy passes
>>>>>>>> for a regular person?
>>>>>>>> 
>>>>>>> 
>>>>>>> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>>>>>>> 
>>>>>>> You will not beat Cloudflare anti bot functionality with a few nginx settings... this is a rabbit hole.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>> -- 
>>>> Payam Tarverdyan Chychi
>>>> _______________________________________________
>>>> 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
>> -- 
>> Payam Tarverdyan Chychi
>> _______________________________________________
>> 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/20230203/69e8746e/attachment.htm>

From venefax at gmail.com  Fri Feb  3 21:34:26 2023
From: venefax at gmail.com (Saint Michael)
Date: Fri, 3 Feb 2023 16:34:26 -0500
Subject: Help beating cloudflare
In-Reply-To: <854D013F-A745-477D-8A9F-7C522760744A@gmail.com>
References: <CAC9cSODT5Xg8CxRG-4hCwkEWLStTGJqR6fBhhnTLa9BQEpNT7Q@mail.gmail.com>
 <854D013F-A745-477D-8A9F-7C522760744A@gmail.com>
Message-ID: <CAC9cSOBa=vPkwmd82tTF7OqiR1w0smCzife8zXD6-SkBX3yAEw@mail.gmail.com>

Cloudflare is reading this.
Please contact me in private.


On Fri, Feb 3, 2023, 4:00 PM Manuel <manuel.baesler at gmail.com> wrote:

> How cool is that.
>
> Now I am curious: what was the solution? :-)
>
> Am 03.02.2023 um 19:46 schrieb Saint Michael <venefax at gmail.com>:
>
> 
> Yes
> 2 years ago nginx was very popular.
>
> Federico
>
> On Fri, Feb 3, 2023, 12:53 PM Payam Chychi <pchychi at gmail.com> wrote:
>
>> Nice job! Though I think what you mean is that you found the answer by
>> searching, chatgpt or otherwise :)
>>
>> Keep in mind, chatgpt is trained on 2y old data :)
>>
>> On Fri, Feb 3, 2023 at 9:14 AM Saint Michael <venefax at gmail.com> wrote:
>>
>>> I won already.
>>> Thanks to chatgpt.
>>> I asked the question and it gave the answer.
>>>
>>> On Fri, Feb 3, 2023, 11:22 AM Payam Chychi <pchychi at gmail.com> wrote:
>>>
>>>> Lol, that is the point…. Proxies do stuff to the connection that makes
>>>> it easy to detect if you know what you are looking for :)
>>>>
>>>> As it stands… you are not going to win this one.
>>>>
>>>>
>>>> On Fri, Feb 3, 2023 at 3:57 AM Saint Michael <venefax at gmail.com> wrote:
>>>>
>>>>> I am sure that it can be done. I am just passing everything to them.
>>>>>
>>>>> On Fri, Feb 3, 2023, 4:39 AM Manuel <manuel.baesler at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> do you forward all headers the browser sends to the server?
>>>>>> The chrome version is very old.
>>>>>> You need to pretend that you are the browser.
>>>>>>
>>>>>> Kind regards,
>>>>>> Manuel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 03.02.2023 um 08:54 schrieb Lukas Tribus <lukas at ltri.eu>:
>>>>>>
>>>>>> 
>>>>>>
>>>>>> On Friday, 3 February 2023, Saint Michael <venefax at gmail.com> wrote:
>>>>>>
>>>>>>> I have a reverse proxy but the newspaper that  I am proxying is
>>>>>>> protected by cloudflare, and the block me immediately, even if I use
>>>>>>> a
>>>>>>> different IP. So somehow they know how to identify my reverse-proxy.
>>>>>>> How is my request different than a regular browser? What is giving
>>>>>>> me up?
>>>>>>> can somebody give an example of what are the rules so my proxy passes
>>>>>>> for a regular person?
>>>>>>
>>>>>>
>>>>>>>
>>>>>> OS fingerprinting, TLS fingerprinting, H2/H3 feature fingerprinting.
>>>>>>
>>>>>> You will not beat Cloudflare anti bot functionality with a few nginx
>>>>>> settings... this is a rabbit hole.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> --
>>>> Payam Tarverdyan Chychi
>>>> _______________________________________________
>>>> 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
>>>
>> --
>> Payam Tarverdyan Chychi
>> _______________________________________________
>> 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/20230203/2273f1e2/attachment-0001.htm>

From relectgustfs at gmail.com  Mon Feb  6 14:13:47 2023
From: relectgustfs at gmail.com (Gus Flowers Starkiller)
Date: Mon, 6 Feb 2023 11:13:47 -0300
Subject: Nginx using HTPPS but without SSL ???
In-Reply-To: <CAH8yC8mw9UamGHcuZhyMaSx+1x3qnMMH7Lt516q+Wp4u=-+-pg@mail.gmail.com>
References: <CAC6R7RhxxXfEfvfqBtJRvDB6rT0nKdQ_29jh_O=TBDUS7CJGXQ@mail.gmail.com>
 <CAH8yC8mw9UamGHcuZhyMaSx+1x3qnMMH7Lt516q+Wp4u=-+-pg@mail.gmail.com>
Message-ID: <CAC6R7RiUMXjo8w90r8CjdydDgwMakvJDyuh4+CfAfYC2zgSYxQ@mail.gmail.com>

Thanks a lot for your help, I will do that !

Greetings!

On Fri, 27 Jan 2023 at 23:12, Jeffrey Walton <noloader at gmail.com> wrote:

> On Thu, Jan 26, 2023 at 8:26 PM Gus Flowers Starkiller
> <relectgustfs at gmail.com> wrote:
> >
> > I need test some pages in my office but with a different domain and I
> don't have SSL certificates.
> >
> > Is there any way to publicate a web site with an alias?
> > For example   mysite1.com (using nginx) to siteok.domain.com ???
>
> You can add an alias or cname record in DNS that says mysite1.com ->
> siteok.domain.com. However, siteok.domain.com must have a TLS
> certificate issued to siteok.domain.com.
>
> One certificate can have multiple domain names by adding the names in
> the Subject Alternate Names (SAN). So one certificate can have
> mysite1.com and siteok.domain.com.
>
> If you don't want to buy the certificates or go through the validation
> process, then you can run your own CA. You install your Root CA
> certificate into the browser store. Then you issue web server
> certificates to hosts for testing.
>
> Running your own CA is safe and effective. It's no different from what
> the public CAs do. I run my own CA at the house.
>
> Jeff
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>


-- 
*Gus Flowers*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230206/e4f6900e/attachment.htm>

From xeioex at nginx.com  Tue Feb  7 23:59:56 2023
From: xeioex at nginx.com (Dmitry Volyntsev)
Date: Tue, 7 Feb 2023 15:59:56 -0800
Subject: njs-0.7.10
Message-ID: <990f544a-9f32-da0b-d160-c4b9212d5423@nginx.com>

Hello,

I'm glad to announce a new feature heavy release of NGINX JavaScript
module (njs).

Notable new features:
- Fetch API extended support, including Headers() and Request()
     constructors:
: async function makeRequest(uri, headers) {
:     let h = new Headers(headers);
:     h.delete("bar");
:     h.append("foo", "xxx");
:     let r = new Request(uri, {headers: h});
:     return await ngx.fetch(r);
: }

- Extended WebCrypto API, most notably JWK support was added:
: async function importSigningJWK(jwk) {
:    return await crypto.subtle.importKey('jwk', jwk,
:                                         {name: "RSASSA-PKCS1-v1_5"},
:                                         true, ['sign']);
: }

- XML parsing module:
: const xml = require("xml");
: let data = `<note><to b="bar" a= "foo" 
 >Tove</to><from>Jani</from></note>`;
: let doc = xml.parse(data);
:
: console.log(doc.note.to.$text) /* 'Tove' */
: console.log(doc.note.to.$attr$b) /* 'bar' */
: console.log(doc.note.$tags[1].$text) /* 'Jani' */


Learn more about njs:

- Overview and introduction:
     https://nginx.org/en/docs/njs/
- NGINX JavaScript in Your Web Server Configuration:
     https://youtu.be/Jc_L6UffFOs
- Extending NGINX with Custom Code:
     https://youtu.be/0CVhq4AUU7M
- Using node modules with njs:
     https://nginx.org/en/docs/njs/node_modules.html
- Writing njs code using TypeScript definition files:
     https://nginx.org/en/docs/njs/typescript.html

Feel free to try it and give us feedback on:

- Github:
     https://github.com/nginx/njs/issues
- Mailing list:
     https://mailman.nginx.org/mailman/listinfo/nginx-devel

Additional examples and howtos can be found here:

- Github:
     https://github.com/nginx/njs-examples


Changes with njs 0.7.10                                      7 Feb 2023
     nginx modules:

     *) Feature: added Request, Response and Headers ctors in Fetch API.

     *) Bugfix: fixed nginx logger callback for calls in master process.

     Core:

     *) Feature: added signal support in CLI.

     *) Feature: added "xml" module for working with XML documents.

     *) Feature: extended support for symmetric and asymmetric keys
        in WebCrypto. Most notably JWK format for importKey() was added.
        generateKey() and exportKey() were also implemented.

     *) Feature: added String.prototype.replaceAll().

     *) Bugfix: fixed for(expr1; conditional syntax error handling.

     *) Bugfix: fixed Object.values() and Object.entries() with external
        objects.

     *) Bugfix: fixed RegExp.prototype[@@replace]().

From kotaro.yasuda at accenture.com  Wed Feb  8 08:03:16 2023
From: kotaro.yasuda at accenture.com (Yasuda, Kotaro)
Date: Wed, 8 Feb 2023 08:03:16 +0000
Subject: About Upcoming new version nginx 
Message-ID: <SN6P114MB095816643CB24E10B4C7AE96F0D89@SN6P114MB0958.NAMP114.PROD.OUTLOOK.COM>

Hi team

I am currently using your nginx 1.22.0 on the server I use. I think nginx 1.24.0 version will be released between mid April and late May this year.
Could you tell me when exactly 1.24.0 will be released?

Regards
Kotaro.Yasuda

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230208/a6d904da/attachment.htm>

From osa at freebsd.org.ru  Wed Feb  8 15:24:26 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Wed, 8 Feb 2023 18:24:26 +0300
Subject: About Upcoming new version nginx
In-Reply-To: <SN6P114MB095816643CB24E10B4C7AE96F0D89@SN6P114MB0958.NAMP114.PROD.OUTLOOK.COM>
References: <SN6P114MB095816643CB24E10B4C7AE96F0D89@SN6P114MB0958.NAMP114.PROD.OUTLOOK.COM>
Message-ID: <Y+O+qta52aKK3v6v@FreeBSD.org.ru>

Hi Kotaro-san,

hope you're doing well.

On Wed, Feb 08, 2023 at 08:03:16AM +0000, Yasuda, Kotaro via nginx wrote:
> 
> I am currently using your nginx 1.22.0 on the server I use. I think nginx
> 1.24.0 version will be released between mid April and late May this year.
> Could you tell me when exactly 1.24.0 will be released?

The general recommendation is to use a recent version from an appropriate
branch, and in case of the stable branch - the recent security release 1.22.1,
please visit https://nginx.org/en/CHANGES-1.22 to get more details.

Usually, the NGINX OSS Development team creates new branch with a
continuously increasing even number in April-May every year:

1.22.x - May 24, 2022
1.20.x - Apr 20, 2021
1.18.x - Apr 21, 2020
1.16.x - Apr 23, 2019
1.14.x - Apr 17, 2018

So, based on that data, we may expect 1.24.x branch and first release in that
branch at the same time of the year 2023.

Hope that helps.

-- 
Sergey A. Osokin

From pluknet at nginx.com  Thu Feb  9 12:46:06 2023
From: pluknet at nginx.com (Sergey Kandaurov)
Date: Thu, 9 Feb 2023 16:46:06 +0400
Subject: nginx-quic packages available
Message-ID: <43CF655D-A718-4F38-88BD-21B47B9F21A9@nginx.com>

Hello.

We are pleased to announce that nginx-quic binary packages are now available.

Check out quic.nginx.org for installation instructions, documentation, and more.

Announcement blog post:
https://www.nginx.com/blog/binary-packages-for-preview-nginx-quic-http3-implementation/

Repository setup instructions:
https://quic.nginx.org/packages.html

-- 
Sergey Kandaurov

From lance at wordkeeper.com  Sat Feb 11 02:24:38 2023
From: lance at wordkeeper.com (Lance Dockins)
Date: Fri, 10 Feb 2023 20:24:38 -0600
Subject: NJS Body File Access Race Condition?
Message-ID: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>

NJS seems to be throwing an error when trying to access the temp body file
created for POST bodies that are larger than the client body buffer size.

I've verified that Nginx and NJS have access to this folder location.  As a
test, I placed a permanent file in the body temp folder location and can
read from that file without an issue in NJS code.  But if I grab the full
path to the temp body file from Nginx and then try to read that file's
contents, NJS throws an error indicating that the file doesn't exist.

Here's a code sample:
let body = '';
if(!r.variables.request_body_file){

body = r.requestText;

}
else{

log.write(logpath, r.variables.request_body_file, r);
let fs = require('fs');
body = fs.readFileSync(r.variables.request_body_file);

}

The log.write call is a utility function that just allows me to log the
contents of the variable in the sample.  In this code,
r.variables.request_body_file logs a full file path to the temp file for
the POST body.  Something like this:
/var/lib/nginx/body/0000000128

But trying to access and read that file immediately following that
yields an error:
2023/02/10 20:14:05 [error] 609307#609307: *1555 js exception: Error: No
such file or directory
    at fs.readFileSync (native)

Again, it's not a permissions issue as a permanent test file exists in the
same folder and is readable in the same code block without an issue.

This code is currently inside of a js_content filter.  Since js_content
runs very late in the process, the temp file seems like it "should" still
be in place.  After all, reading r.requestText works just fine.  The only
time the problem surfaces is when the client body exceeds the buffer size
(even if the buffer size is high) as that's where file access has to
occur.  Since the POST bodies can sometimes be very large in this
particular route, it's not really a viable option to try to match the
client body buffer size to the client body max size.  So being able to
access and read the POST body temp file is important since there are bound
to be situations where a request crosses beyond the buffer size regardless
of how high it goes (not that higher is necessarily always a good idea).

This sort of NJS behavior "seems" like some sort of race condition where
NJS is trying to access the file after Nginx has already disposed of it.
Since this is a js_content directive, it should be blocking and it seems to
be one of the few stages where access to the POST body is even possible.
So it's unclear why the client body buffer file wouldn't exist at the time
that this code runs.

Is this a bug in NJS?  Or is there some sort of alternative solution (e.g.
settings adjustment in Nginx itself) that might resolve the problem?

Thanks in advance for any insights.


-- 
Lance Dockins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230210/0562c4c8/attachment.htm>

From lance at wordkeeper.com  Sat Feb 11 02:29:09 2023
From: lance at wordkeeper.com (Lance Dockins)
Date: Fri, 10 Feb 2023 20:29:09 -0600
Subject: NJS Body File Access Race Condition?
In-Reply-To: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>
References: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>
Message-ID: <2b6630ca-1742-49c5-af4b-ba5cb1b92799@Spark>

If it matters, I’m using Nginx 1.23.3 and NJS 0.7.10


--
Lance Dockins

On Feb 10, 2023 at 8:24 PM -0600, Lance Dockins <lance at wordkeeper.com>, wrote:
> NJS seems to be throwing an error when trying to access the temp body file created for POST bodies that are larger than the client body buffer size.
>
> I've verified that Nginx and NJS have access to this folder location.  As a test, I placed a permanent file in the body temp folder location and can read from that file without an issue in NJS code.  But if I grab the full path to the temp body file from Nginx and then try to read that file's contents, NJS throws an error indicating that the file doesn't exist.
>
> Here's a code sample:
> let body = '';
> if(!r.variables.request_body_file){
> > quote_type
> > body = r.requestText;
> }
> else{
> > quote_type
> > log.write(logpath, r.variables.request_body_file, r);
> > let fs = require('fs');
> > body = fs.readFileSync(r.variables.request_body_file);
> }
>
> The log.write call is a utility function that just allows me to log the contents of the variable in the sample.  In this code, r.variables.request_body_file logs a full file path to the temp file for the POST body.  Something like this:
> /var/lib/nginx/body/0000000128
>
> But trying to access and read that file immediately following that yields an error:
> 2023/02/10 20:14:05 [error] 609307#609307: *1555 js exception: Error: No such file or directory
>     at fs.readFileSync (native)
>
> Again, it's not a permissions issue as a permanent test file exists in the same folder and is readable in the same code block without an issue.
>
> This code is currently inside of a js_content filter.  Since js_content runs very late in the process, the temp file seems like it "should" still be in place.  After all, reading r.requestText works just fine.  The only time the problem surfaces is when the client body exceeds the buffer size (even if the buffer size is high) as that's where file access has to occur.  Since the POST bodies can sometimes be very large in this particular route, it's not really a viable option to try to match the client body buffer size to the client body max size.  So being able to access and read the POST body temp file is important since there are bound to be situations where a request crosses beyond the buffer size regardless of how high it goes (not that higher is necessarily always a good idea).
>
> This sort of NJS behavior "seems" like some sort of race condition where NJS is trying to access the file after Nginx has already disposed of it.  Since this is a js_content directive, it should be blocking and it seems to be one of the few stages where access to the POST body is even possible.  So it's unclear why the client body buffer file wouldn't exist at the time that this code runs.
>
> Is this a bug in NJS?  Or is there some sort of alternative solution (e.g. settings adjustment in Nginx itself) that might resolve the problem?
>
> Thanks in advance for any insights.
>
>
> --
> Lance Dockins
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230210/cc4e3629/attachment.htm>

From xeioex at nginx.com  Sat Feb 11 02:49:48 2023
From: xeioex at nginx.com (Dmitry Volyntsev)
Date: Fri, 10 Feb 2023 18:49:48 -0800
Subject: NJS Body File Access Race Condition?
In-Reply-To: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>
References: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>
Message-ID: <a9088f79-810e-d07c-49be-b673991a2164@nginx.com>

Hi Lance,

On 10.02.2023 18:24, Lance Dockins wrote:
> This sort of NJS behavior "seems" like some sort of race condition 
> where NJS is trying to access the file after Nginx has already 
> disposed of it.  Since this is a js_content directive, it should be 
> blocking and it seems to be one of the few stages where access to the 
> POST body is even possible.  So it's unclear why the client body 
> buffer file wouldn't exist at the time that this code runs.
>

Take a look at 
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only.




From lance at wordkeeper.com  Sat Feb 11 03:10:23 2023
From: lance at wordkeeper.com (Lance Dockins)
Date: Fri, 10 Feb 2023 21:10:23 -0600
Subject: NJS Body File Access Race Condition?
In-Reply-To: <a9088f79-810e-d07c-49be-b673991a2164@nginx.com>
References: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>
 <a9088f79-810e-d07c-49be-b673991a2164@nginx.com>
Message-ID: <68fc43b9-cc7b-4ca1-b13e-01087177d173@Spark>

Thanks, Dmitry.

Is it correct to assume that this setting just forces all POST bodies into a file (like shutting off client body buffers)?  And would that be true even with the “clean” directive?

The “clean” value sounds like it just retains the POST body file until the request completes (at which point it’s cleaned), but if that’s an incorrect understanding, please let me know.

I was sort of hoping to use memory buffers for smaller request body sizes and only use file for larger request bodies.  But if this setting is the only solution to the problem (or if one of the settings is going to do what I’m describing), I’ll go with that.


--
Lance Dockins

On Feb 10, 2023 at 8:49 PM -0600, Dmitry Volyntsev <xeioex at nginx.com>, wrote:
> Hi Lance,
>
> On 10.02.2023 18:24, Lance Dockins wrote:
> > This sort of NJS behavior "seems" like some sort of race condition
> > where NJS is trying to access the file after Nginx has already
> > disposed of it.  Since this is a js_content directive, it should be
> > blocking and it seems to be one of the few stages where access to the
> > POST body is even possible.  So it's unclear why the client body
> > buffer file wouldn't exist at the time that this code runs.
> >
>
> Take a look at
> http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230210/2fbae1b6/attachment-0001.htm>

From xeioex at nginx.com  Sat Feb 11 05:57:45 2023
From: xeioex at nginx.com (Dmitry Volyntsev)
Date: Fri, 10 Feb 2023 21:57:45 -0800
Subject: NJS Body File Access Race Condition?
In-Reply-To: <68fc43b9-cc7b-4ca1-b13e-01087177d173@Spark>
References: <CANVkfHQG6qFKzGOo8gs740QJn5EcC8OQzXX5SQXFb7RVjH8YbA@mail.gmail.com>
 <a9088f79-810e-d07c-49be-b673991a2164@nginx.com>
 <68fc43b9-cc7b-4ca1-b13e-01087177d173@Spark>
Message-ID: <c490467f-ab47-f54c-fb0d-662f0e8b0c26@nginx.com>


Hi Lance,

On 2/10/23 7:10 PM, Lance Dockins wrote:
> Thanks, Dmitry.
> 
> Is it correct to assume that this setting just forces all POST bodies 
> into a file (like shutting off client body buffers)?  And would that be 
> true even with the “clean” directive?
 >
 > The “clean” value sounds like it just retains the POST body file until
 > the request completes (at which point it’s cleaned), but if that’s an
 > incorrect understanding, please let me know.

yes, "client_body_in_file_only clean" ensures two things:

1) the request body is always in a file
2) the temporary file is unlinked from a directory at the moment the 
request finishes.


By default, client_body_in_file_only is off which means
that the file is unlinked from directory right away at the moment
the file is created (thus making the file inaccessible by a name, only
	through open file descriptor).


> I was sort of hoping to use memory buffers for smaller request body 
> sizes and only use file for larger request bodies.  But if this setting 
> is the only solution to the problem (or if one of the settings is going 
> to do what I’m describing), I’ll go with that.


The another option is to increase the  client_body_buffer_size ensuring the
the body is always in memory.

> 
> 
> --
> Lance Dockins
> 
> On Feb 10, 2023 at 8:49 PM -0600, Dmitry Volyntsev <xeioex at nginx.com>, 
> wrote:
>> Hi Lance,
>>
>> On 10.02.2023 18:24, Lance Dockins wrote:
>>> This sort of NJS behavior "seems" like some sort of race condition
>>> where NJS is trying to access the file after Nginx has already
>>> disposed of it.  Since this is a js_content directive, it should be
>>> blocking and it seems to be one of the few stages where access to the
>>> POST body is even possible.  So it's unclear why the client body
>>> buffer file wouldn't exist at the time that this code runs.
>>>
>>
>> Take a look at
>> http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only.
>>
>>
>>
>>

From nginx-4dk5spqe at compilenix.org  Sun Feb 12 16:31:30 2023
From: nginx-4dk5spqe at compilenix.org (Kevin Weis)
Date: Sun, 12 Feb 2023 17:31:30 +0100
Subject: Nginx won't build with xslt into static linked binary
Message-ID: <94adeef2-5fca-2fe3-5d16-71152636a61b@compilenix.org>

Hi,
I aim to build nginx from source, statically linked, and run into issues 
when `http_xslt_module` is enabled or I'm building with NJS 0.7.10 
(which also needs xslt).

I've created a simplified docker build to debug this issue at 
https://git.compilenix.org/CompileNix/docker-nginx-static

The error occures while running `./auto/configure` if 
`--with-ld-opt="-static"` is added. The build succeeds without it 
(remove line 176 from Dockerfile).

The configure ends with:
```
checking for libxslt ... not found
checking for libxslt in /usr/local/ ... not found
checking for libxslt in /usr/pkg/ ... not found
checking for libxslt in /opt/local/ ... not found

./auto/configure: error: the HTTP XSLT module requires the libxml2/libxslt
libraries. You can either do not enable the module or install the libraries.
```

The issue is not that libxml2 and libxslt aren't installed, they are.

I've looked into why libxslt is reported to be "not found" by inspecting 
the configure log file `objs/autoconf.err`, which shows the following error:
``
checking for libxslt

/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: 
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../lib/libxml2.a(libxml2_la-xmlIO.o): 
in function `xmlFreeZMemBuff':
/home/buildozer/aports/main/libxml2/src/libxml2-2.10.3/xmlIO.c:1482: 
undefined reference to `deflateEnd'
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: 
/usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../lib/libxml2.a(libxml2_la-xmlIO.o): 
in function `xmlGzfileOpenW':
/home/buildozer/aports/main/libxml2/src/libxml2-2.10.3/xmlIO.c:1172: 
undefined reference to `gzdopen'

<for more see full build log linked below>
```

Here is the full build log: 
https://compilenix.org/static/95Yeyaxv/build-static.log

If you are wondering why I also build libxslt from source instead of 
using the alpine `libxslt-dev` package.. `libxslt-dev` does not contain 
"libxslt.a", which is required for static linking.

Additionally: I've also looked into other distros like ubuntu, fedora or 
gentoo. None of them install "libxslt.a" and show the same configure 
error messages.

Steps to reproduce:
```
git clone https://git.compilenix.org/CompileNix/docker-nginx-static.git
cd docker-nginx-static
./build.sh -t docker-nginx-static --no-cache | tee build.log
```

Any help, suggestions or hints are very welcome :)

-- 
Best regards
Kevin Weis
Pronouns: he / him

https://compilenix.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x3B3F8B753D8DDB10.asc
Type: application/pgp-keys
Size: 1371 bytes
Desc: OpenPGP public key
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230212/5ae20607/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230212/5ae20607/attachment-0001.bin>

From mdounin at mdounin.ru  Sun Feb 12 22:42:52 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 13 Feb 2023 01:42:52 +0300
Subject: Nginx won't build with xslt into static linked binary
In-Reply-To: <94adeef2-5fca-2fe3-5d16-71152636a61b@compilenix.org>
References: <94adeef2-5fca-2fe3-5d16-71152636a61b@compilenix.org>
Message-ID: <Y+lrbFxUWJYWBKVx@mdounin.ru>

Hello!

On Sun, Feb 12, 2023 at 05:31:30PM +0100, Kevin Weis via nginx wrote:

> Hi,
> I aim to build nginx from source, statically linked, and run into issues 
> when `http_xslt_module` is enabled or I'm building with NJS 0.7.10 
> (which also needs xslt).
> 
> I've created a simplified docker build to debug this issue at 
> https://git.compilenix.org/CompileNix/docker-nginx-static
> 
> The error occures while running `./auto/configure` if 
> `--with-ld-opt="-static"` is added. The build succeeds without it 
> (remove line 176 from Dockerfile).
> 
> The configure ends with:
> ```
> checking for libxslt ... not found
> checking for libxslt in /usr/local/ ... not found
> checking for libxslt in /usr/pkg/ ... not found
> checking for libxslt in /opt/local/ ... not found
> 
> ./auto/configure: error: the HTTP XSLT module requires the libxml2/libxslt
> libraries. You can either do not enable the module or install the libraries.
> ```
> 
> The issue is not that libxml2 and libxslt aren't installed, they are.
> 
> I've looked into why libxslt is reported to be "not found" by inspecting 
> the configure log file `objs/autoconf.err`, which shows the following error:
> ``
> checking for libxslt
> 
> /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: 
> /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../lib/libxml2.a(libxml2_la-xmlIO.o): 
> in function `xmlFreeZMemBuff':
> /home/buildozer/aports/main/libxml2/src/libxml2-2.10.3/xmlIO.c:1482: 
> undefined reference to `deflateEnd'
> /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: 
> /usr/lib/gcc/x86_64-alpine-linux-musl/12.2.1/../../../../lib/libxml2.a(libxml2_la-xmlIO.o): 
> in function `xmlGzfileOpenW':
> /home/buildozer/aports/main/libxml2/src/libxml2-2.10.3/xmlIO.c:1172: 
> undefined reference to `gzdopen'
> 
> <for more see full build log linked below>
> ```
> 
> Here is the full build log: 
> https://compilenix.org/static/95Yeyaxv/build-static.log
> 
> If you are wondering why I also build libxslt from source instead of 
> using the alpine `libxslt-dev` package.. `libxslt-dev` does not contain 
> "libxslt.a", which is required for static linking.
> 
> Additionally: I've also looked into other distros like ubuntu, fedora or 
> gentoo. None of them install "libxslt.a" and show the same configure 
> error messages.
> 
> Steps to reproduce:
> ```
> git clone https://git.compilenix.org/CompileNix/docker-nginx-static.git
> cd docker-nginx-static
> ./build.sh -t docker-nginx-static --no-cache | tee build.log
> ```
> 
> Any help, suggestions or hints are very welcome :)

Static linking requires more than just "-static".  In particular, 
for all the libraries being used you'll have to manually provide 
library dependencies.

The particular error suggests that libxml2 depends on zlib, so 
something like "--with-ld-opt="-static -lz"" should help.  
Likely there will be other similar errors and you'll have to 
include other libraries as well.  For example, on FreeBSD static 
linking with libxslt requires "-static -lz -lm -llzma -lmd".

Something like

    pkg-config --static libxslt

might be a good starting point for full list of required 
libraries, assuming libxslt package information is properly 
installed.  Alternatively, ldd on the dynamic library might be a 
good start.

Note well that in general it might not be a good idea to compile 
things statically unless you have some good reasons to and 
understand possible consequences.

-- 
Maxim Dounin
http://mdounin.ru/

From pgnet.dev at gmail.com  Wed Feb 15 17:25:09 2023
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Wed, 15 Feb 2023 12:25:09 -0500
Subject: "ssl_stapling" ignored warning on boot with LE certs?
Message-ID: <1386abb5-20c2-6836-171f-ac11d3d5132f@gmail.com>

i run

	nginx -v
		nginx version: nginx/1.23.3 (Local Build)

nginx is launched on boot with a systemd service

my site's ssl enabled, using letsencrypt certs

in my boot logs, i see

	Feb 15 11:54:03 svr017 nginx[912]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "r3.o.lencr.org/" in the certificate "/sec/svr017/fullchain.ec.crt.pem"

nginx site config includes

     ssl_trusted_certificate   "/sec/svr017/intermediate_ca.ec.crt.pem";
     ssl_certificate           "/sec/svr017/fullchain.ec.crt.pem";
     ssl_certificate_key       "/sec/svr017/priv.ec.key";


	ssl_stapling on;
	ssl_stapling_verify on;
	ssl_ocsp on;
	ssl_ocsp_cache shared:OCSP:10m;
	ssl_stapling_responder http://r3.o.lencr.org/;
	ssl_ocsp_responder     http://r3.o.lencr.org/;

checking the cert

	openssl x509 -noout -text -in /sec/svr017/fullchain.ec.crt.pem | grep -i ocsp -A2 -B1
	            Authority Information Access:
	                OCSP - URI:http://r3.o.lencr.org
	                CA Issuers - URI:http://r3.i.lencr.org/
	            X509v3 Subject Alternative Name:

from the host

	dig A r3.o.lencr.org +short
		o.lencr.edgesuite.net.
		a1887.dscq.akamai.net.
		23.215.130.112
		23.215.130.106
		23.215.130.113
		23.215.130.88

	telnet -4 r3.o.lencr.org 80
		Trying 23.63.77.32...
		Connected to r3.o.lencr.org.
		Escape character is '^]'.

	curl -Ii http://r3.o.lencr.org/
		HTTP/1.1 200 OK
		Server: nginx
		Content-Length: 0
		Cache-Control: max-age=5863
		Expires: Wed, 15 Feb 2023 18:52:39 GMT
		Date: Wed, 15 Feb 2023 17:14:56 GMT
		Connection: keep-alive

is this warning due to a nginx misconfig?  or a cert issue?

From nginx at onekarlo.com  Thu Feb 16 06:48:23 2023
From: nginx at onekarlo.com (JK)
Date: Thu, 16 Feb 2023 14:48:23 +0800
Subject: nginx does not start automatically, what have I done?
Message-ID: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>

An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230216/f9e2087a/attachment.htm>

From mdounin at mdounin.ru  Thu Feb 16 13:59:35 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 16 Feb 2023 16:59:35 +0300
Subject: "ssl_stapling" ignored warning on boot with LE certs?
In-Reply-To: <1386abb5-20c2-6836-171f-ac11d3d5132f@gmail.com>
References: <1386abb5-20c2-6836-171f-ac11d3d5132f@gmail.com>
Message-ID: <Y+42x3cnbv8AAgeq@mdounin.ru>

Hello!

On Wed, Feb 15, 2023 at 12:25:09PM -0500, PGNet Dev wrote:

> i run
> 
> 	nginx -v
> 		nginx version: nginx/1.23.3 (Local Build)
> 
> nginx is launched on boot with a systemd service
> 
> my site's ssl enabled, using letsencrypt certs
> 
> in my boot logs, i see
> 
> 	Feb 15 11:54:03 svr017 nginx[912]: nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "r3.o.lencr.org/" in the certificate "/sec/svr017/fullchain.ec.crt.pem"

[...]

> is this warning due to a nginx misconfig?  or a cert issue?

The error message suggests there is something wrong with DNS on 
your host.

If this happens only on boot but not when you restart/reload nginx 
after boot, this might indicate that DNS is not yet properly 
available when nginx starts.  One possible reason is that nginx 
systemd service is not properly configured to depend on DNS being 
available: for nginx to start properly you may want to ensure that 
there is Wants= and After= dependency on network-online.target, 
and After= dependency on nss-lookup.target, see nginx.service as 
shipped by nginx.org nginx packages[1] for an example.

[1] http://hg.nginx.org/pkg-oss/file/tip/debian/debian/nginx.service

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Thu Feb 16 14:18:52 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 16 Feb 2023 17:18:52 +0300
Subject: nginx does not start automatically, what have I done?
In-Reply-To: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
References: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
Message-ID: <Y+47TCOrCEmW1wrx@mdounin.ru>

Hello!

On Thu, Feb 16, 2023 at 02:48:23PM +0800, JK wrote:

>    Hello, it is my first time posting here, and I appreciate the
>    opportunity to share my experience with nginx.
> 
> 
>    Just to give you background, I am using a VPS from Racknerd, and I use
>    CWP (Control Web Panel), which is pretty similar to cPanel.
> 
> 
>    I tried to update the repo and use dnf upgrade -y, and what happened
>    was, after restarting the server, nginx did not start automatically.
> 
> 
>    Here is the log of nginx:
> 
> 
>    ● nginx.service - The nginx HTTP and reverse proxy server
>       Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled;
>    vendor preset: disabled)
>       Active: failed (Result: exit-code) since Wed 2023-02-15 17:29:03
>    EST; 7h ago
>      Process: 779 ExecStartPre=/usr/sbin/nginx -t (code=exited,
>    status=1/FAILURE)
>      Process: 776 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited,
>    status=0/SUCCESS)
>    Feb 15 17:29:02 racknerd-f5**** systemd[1]: Starting The nginx HTTP and
>    reverse proxy server...
>    Feb 15 17:29:02 racknerd-f5**** nginx[779]: nginx: the configuration
>    file /etc/nginx/nginx.conf syntax is ok
>    Feb 15 17:29:03 racknerd-f5**** nginx[779]: nginx: [emerg] bind() to
>    100.xx.xx.xx:80 failed (99: Cannot assign requested address)
>    Feb 15 17:29:03 racknerd-f5**** nginx[779]: nginx: configuration file
>    /etc/nginx/nginx.conf test failed
>    Feb 15 17:29:03 racknerd-f5**** systemd[1]: nginx.service: Control
>    process exited, code=exited status=1
>    Feb 15 17:29:03 racknerd-f5**** systemd[1]: nginx.service: Failed with
>    result 'exit-code'.
>    Feb 15 17:29:03 racknerd-f5**** systemd[1]: Failed to start The nginx
>    HTTP and reverse proxy server.
> 
> 
>    The solution is to manually start nginx after a minute or two.

The error message "bind() to 100.xx.xx.xx:80 failed (99: Cannot 
assign requested address)" suggests the IP address you are trying 
to use is not available when nginx starts.

Possible options to fix this include:

- Make sure nginx systemd service properly depends on the network 
  being available (After=/Wants= network-online.target is usually 
  good enough, though you may need to also enable proper wait 
  service, see [1]).

- Reconfigure nginx to listen on the wildcard address instead, so 
  it won't try to bind on IP addresses not yet available when it 
  starts.

Hope this helps.

[1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

-- 
Maxim Dounin
http://mdounin.ru/

From pgnet.dev at gmail.com  Thu Feb 16 14:23:21 2023
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 16 Feb 2023 09:23:21 -0500
Subject: "ssl_stapling" ignored warning on boot with LE certs?
In-Reply-To: <Y+42x3cnbv8AAgeq@mdounin.ru>
References: <1386abb5-20c2-6836-171f-ac11d3d5132f@gmail.com>
 <Y+42x3cnbv8AAgeq@mdounin.ru>
Message-ID: <b97094b1-2749-75a9-68f0-0d4bdf6809a1@gmail.com>

hi,

> The error message suggests there is something wrong with DNS on> your host.
> If this happens only on boot but not when you restart/reload nginx
> after boot,

ah.  testing, yep, that does seem to be the case

> this might indicate that DNS is not yet properly
> available when nginx starts.  One possible reason is that nginx
> systemd service is not properly configured to depend on DNS being
> available: for nginx to start properly you may want to ensure that
> there is Wants= and After= dependency on network-online.target,
> and After= dependency on nss-lookup.target, see nginx.service as
> shipped by nginx.org nginx packages[1] for an example.

i'd added/use unbound as local resolver.

changing both

	edit /etc/systemd/system/nginx.service
-		After=network-online.target
-		Wants=network-online.target
+		After=network-online.target nss-lookup.target unbound.target
+		Wants=network-online.target nss-lookup.target unbound.target

and

	edit /etc/systemd/system/nginx.service
-		networks: files dns
+		networks: dns files

does the trick.

i wasn't noticing any DNS issues anywhere (else); just this ocsp fail.  good catch, thx!

o/

From nginx at onekarlo.com  Thu Feb 16 15:13:59 2023
From: nginx at onekarlo.com (nginx at onekarlo.com)
Date: Thu, 16 Feb 2023 15:13:59 +0000
Subject: nginx does not start automatically, what have I done?
In-Reply-To: <Y+47TCOrCEmW1wrx@mdounin.ru>
References: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
 <Y+47TCOrCEmW1wrx@mdounin.ru>
Message-ID: <AM7PR02MB57971838AC12C5B09DE8DE64A4A09@AM7PR02MB5797.eurprd02.prod.outlook.com>

Hello,

Thanks for replying. I appreciate the thorough response!
I found the solution online.
And it worked!

nano /etc/sysctl.conf # allow processes to bind to the non-local address net.ipv4.ip_nonlocal_bind = 1
sysctl -p /etc/sysctl.conf

What do you think about it?

Thanks.

From: nginx <nginx-bounces at nginx.org> on behalf of Maxim Dounin <mdounin at mdounin.ru>
Date: Thursday, February 16, 2023 at 22:19
To: nginx at nginx.org <nginx at nginx.org>
Subject: Re: nginx does not start automatically, what have I done?
Hello!

On Thu, Feb 16, 2023 at 02:48:23PM +0800, JK wrote:

>    Hello, it is my first time posting here, and I appreciate the
>    opportunity to share my experience with nginx.
>
>
>    Just to give you background, I am using a VPS from Racknerd, and I use
>    CWP (Control Web Panel), which is pretty similar to cPanel.
>
>
>    I tried to update the repo and use dnf upgrade -y, and what happened
>    was, after restarting the server, nginx did not start automatically.
>
>
>    Here is the log of nginx:
>
>
>    ● nginx.service - The nginx HTTP and reverse proxy server
>       Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled;
>    vendor preset: disabled)
>       Active: failed (Result: exit-code) since Wed 2023-02-15 17:29:03
>    EST; 7h ago
>      Process: 779 ExecStartPre=/usr/sbin/nginx -t (code=exited,
>    status=1/FAILURE)
>      Process: 776 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited,
>    status=0/SUCCESS)
>    Feb 15 17:29:02 racknerd-f5**** systemd[1]: Starting The nginx HTTP and
>    reverse proxy server...
>    Feb 15 17:29:02 racknerd-f5**** nginx[779]: nginx: the configuration
>    file /etc/nginx/nginx.conf syntax is ok
>    Feb 15 17:29:03 racknerd-f5**** nginx[779]: nginx: [emerg] bind() to
>    100.xx.xx.xx:80 failed (99: Cannot assign requested address)
>    Feb 15 17:29:03 racknerd-f5**** nginx[779]: nginx: configuration file
>    /etc/nginx/nginx.conf test failed
>    Feb 15 17:29:03 racknerd-f5**** systemd[1]: nginx.service: Control
>    process exited, code=exited status=1
>    Feb 15 17:29:03 racknerd-f5**** systemd[1]: nginx.service: Failed with
>    result 'exit-code'.
>    Feb 15 17:29:03 racknerd-f5**** systemd[1]: Failed to start The nginx
>    HTTP and reverse proxy server.
>
>
>    The solution is to manually start nginx after a minute or two.

The error message "bind() to 100.xx.xx.xx:80 failed (99: Cannot
assign requested address)" suggests the IP address you are trying
to use is not available when nginx starts.

Possible options to fix this include:

- Make sure nginx systemd service properly depends on the network
  being available (After=/Wants= network-online.target is usually
  good enough, though you may need to also enable proper wait
  service, see [1]).

- Reconfigure nginx to listen on the wildcard address instead, so
  it won't try to bind on IP addresses not yet available when it
  starts.

Hope this helps.

[1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

--
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/20230216/649a0efa/attachment.htm>

From mdounin at mdounin.ru  Fri Feb 17 11:30:37 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Feb 2023 14:30:37 +0300
Subject: nginx does not start automatically, what have I done?
In-Reply-To: <AM7PR02MB57971838AC12C5B09DE8DE64A4A09@AM7PR02MB5797.eurprd02.prod.outlook.com>
References: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
 <Y+47TCOrCEmW1wrx@mdounin.ru>
 <AM7PR02MB57971838AC12C5B09DE8DE64A4A09@AM7PR02MB5797.eurprd02.prod.outlook.com>
Message-ID: <Y+9lXZt7m8x6+rNf@mdounin.ru>

Hello!

On Thu, Feb 16, 2023 at 03:13:59PM +0000, nginx at onekarlo.com wrote:

> Thanks for replying. I appreciate the thorough response!
> I found the solution online.
> And it worked!
> 
> nano /etc/sysctl.conf # allow processes to bind to the non-local address net.ipv4.ip_nonlocal_bind = 1
> sysctl -p /etc/sysctl.conf
> 
> What do you think about it?

It should work around the issue, though the obvious downside is 
that the whole system will not be able to detect real errors, such 
as mistyped local addresses.

A better solution might be to ensure proper startup order.  This 
should also fix other potential issues, such as non-working DNS 
resolution during nginx startup.

On the other hand, if it works for you, it's probably good enough.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx at onekarlo.com  Fri Feb 17 12:34:23 2023
From: nginx at onekarlo.com (nginx at onekarlo.com)
Date: Fri, 17 Feb 2023 12:34:23 +0000
Subject: nginx does not start automatically, what have I done?
In-Reply-To: <Y+9lXZt7m8x6+rNf@mdounin.ru>
References: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
 <Y+47TCOrCEmW1wrx@mdounin.ru>
 <AM7PR02MB57971838AC12C5B09DE8DE64A4A09@AM7PR02MB5797.eurprd02.prod.outlook.com>
 <Y+9lXZt7m8x6+rNf@mdounin.ru>
Message-ID: <AM7PR02MB579721ED281C3439E2FBE1D5A4A19@AM7PR02MB5797.eurprd02.prod.outlook.com>

How will I be able to fix it and avoid the use of this method?

Please do help me, thanks!

From: nginx <nginx-bounces at nginx.org> on behalf of Maxim Dounin <mdounin at mdounin.ru>
Date: Friday, February 17, 2023 at 19:30
To: nginx at nginx.org <nginx at nginx.org>
Subject: Re: nginx does not start automatically, what have I done?
Hello!

On Thu, Feb 16, 2023 at 03:13:59PM +0000, nginx at onekarlo.com wrote:

> Thanks for replying. I appreciate the thorough response!
> I found the solution online.
> And it worked!
>
> nano /etc/sysctl.conf # allow processes to bind to the non-local address net.ipv4.ip_nonlocal_bind = 1
> sysctl -p /etc/sysctl.conf
>
> What do you think about it?

It should work around the issue, though the obvious downside is
that the whole system will not be able to detect real errors, such
as mistyped local addresses.

A better solution might be to ensure proper startup order.  This
should also fix other potential issues, such as non-working DNS
resolution during nginx startup.

On the other hand, if it works for you, it's probably good enough.

--
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/20230217/a77d9baa/attachment.htm>

From mdounin at mdounin.ru  Fri Feb 17 13:06:03 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 17 Feb 2023 16:06:03 +0300
Subject: nginx does not start automatically, what have I done?
In-Reply-To: <AM7PR02MB579721ED281C3439E2FBE1D5A4A19@AM7PR02MB5797.eurprd02.prod.outlook.com>
References: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
 <Y+47TCOrCEmW1wrx@mdounin.ru>
 <AM7PR02MB57971838AC12C5B09DE8DE64A4A09@AM7PR02MB5797.eurprd02.prod.outlook.com>
 <Y+9lXZt7m8x6+rNf@mdounin.ru>
 <AM7PR02MB579721ED281C3439E2FBE1D5A4A19@AM7PR02MB5797.eurprd02.prod.outlook.com>
Message-ID: <Y+97u9mXzv5pzz79@mdounin.ru>

Hello!

On Fri, Feb 17, 2023 at 12:34:23PM +0000, nginx at onekarlo.com wrote:

> How will I be able to fix it and avoid the use of this method?
> 
> Please do help me, thanks!

As suggested in the original response, first thing to check is the 
systemd service you are using to start nginx.  It should contain
"After=" and "Wants=" clauses with "network-online.target", see 
http://hg.nginx.org/pkg-oss/file/tip/debian/debian/nginx.service 
for an example.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx at onekarlo.com  Fri Feb 17 13:07:35 2023
From: nginx at onekarlo.com (nginx at onekarlo.com)
Date: Fri, 17 Feb 2023 13:07:35 +0000
Subject: nginx does not start automatically, what have I done?
In-Reply-To: <Y+97u9mXzv5pzz79@mdounin.ru>
References: <D8004D6F-42AA-0F4B-8C94-E99A8E5162B3@hxcore.ol>
 <Y+47TCOrCEmW1wrx@mdounin.ru>
 <AM7PR02MB57971838AC12C5B09DE8DE64A4A09@AM7PR02MB5797.eurprd02.prod.outlook.com>
 <Y+9lXZt7m8x6+rNf@mdounin.ru>
 <AM7PR02MB579721ED281C3439E2FBE1D5A4A19@AM7PR02MB5797.eurprd02.prod.outlook.com>
 <Y+97u9mXzv5pzz79@mdounin.ru>
Message-ID: <AM7PR02MB5797D382E07E5A924A82DA0CA4A19@AM7PR02MB5797.eurprd02.prod.outlook.com>

Oh, wait. I am using AlmaLinux and CWP (Control Web Panel) which was known before as CentOS Web Panel.

From: nginx <nginx-bounces at nginx.org> on behalf of Maxim Dounin <mdounin at mdounin.ru>
Date: Friday, February 17, 2023 at 21:06
To: nginx at nginx.org <nginx at nginx.org>
Subject: Re: nginx does not start automatically, what have I done?
Hello!

On Fri, Feb 17, 2023 at 12:34:23PM +0000, nginx at onekarlo.com wrote:

> How will I be able to fix it and avoid the use of this method?
>
> Please do help me, thanks!

As suggested in the original response, first thing to check is the
systemd service you are using to start nginx.  It should contain
"After=" and "Wants=" clauses with "network-online.target", see
http://hg.nginx.org/pkg-oss/file/tip/debian/debian/nginx.service
for an example.

--
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/20230217/2d9951ea/attachment.htm>

From ivo.welch at gmail.com  Sun Feb 19 01:27:45 2023
From: ivo.welch at gmail.com (Ivo Welch)
Date: Sat, 18 Feb 2023 17:27:45 -0800
Subject: FAQ Suggestions
Message-ID: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>

1. is this mailing list the correct place to suggest additions to the FAQ?

2. why does

```
location /wth {
   root /var/www/fcgi-bin/;
   index wth-root.html;
 }
```

not resolve '/wth' (but incidentally does resolve '/wth-root.html',
though not '/wth-root').

I have been scratching my head about this for the longest time.

From me at nanaya.net  Sun Feb 19 06:26:51 2023
From: me at nanaya.net (nanaya)
Date: Sun, 19 Feb 2023 15:26:51 +0900
Subject: FAQ Suggestions
In-Reply-To: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
Message-ID: <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>

Hi

On Sun, Feb 19, 2023, at 10:27, Ivo Welch wrote:
> 2. why does
>
> ```
> location /wth {
>    root /var/www/fcgi-bin/;
>    index wth-root.html;
>  }
> ```
>
> not resolve '/wth' (but incidentally does resolve '/wth-root.html',
> though not '/wth-root').
>

it's one of the common confusions. Just /wth doesn't trigger index listing as it doesn't end with a forward slash. /wth-root does match because /wth matches anything that starts with /wth (some people seem to think it matches /wth/ directory but it really doesn't - it's just prefix matching after all).

If you have /var/www/fcgi-bin/wtha.html file and try accessing /wtha.html, it'll return that file, for example. Same with /wth-root.html as you experienced. 

Back to /wth, it'll try to return file /var/www/fcgi-bin/wth (which probably doesn't exist).

If what you actually want is to to match /wth/, it needs to be `location /wth/`. Although then it can't be accessed through /wth as it doesn't match anymore (unless it exists as directory in other location like `location /`). In which case I usually add `location = /wth { return 302 /wth/; }` to fix this one special case.

From venefax at gmail.com  Sun Feb 19 06:52:12 2023
From: venefax at gmail.com (Saint Michael)
Date: Sun, 19 Feb 2023 01:52:12 -0500
Subject: Private location does not work
In-Reply-To: <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
Message-ID: <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>

>
> I have two locations

/xxxxx
/yyyyyy

the public one is /yyyyy, nobody is supposed to access /xxxxx from the
Internet.
Inside /yyyy, I call /xxxxx, but if I do this:

location /asrxxxx {
default_type  'text/html; charset=UTF-8';
allow 127.0.0.1;
 deny all;

it fails with forbidden. But I am using only from another location inside
the same server.

How do I protect internal service locations and at the same time use them?



>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230219/cd5f23f8/attachment.htm>

From francis at daoine.org  Sun Feb 19 13:19:48 2023
From: francis at daoine.org (Francis Daly)
Date: Sun, 19 Feb 2023 13:19:48 +0000
Subject: Private location does not work
In-Reply-To: <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
Message-ID: <20230219131948.GD21799@daoine.org>

On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:

Hi there,

> it fails with forbidden. But I am using only from another location inside
> the same server.
> 
> How do I protect internal service locations and at the same time use them?

If you are asking "how do I ensure that a location{} can only be used for
internal redirects/requests", then you want http://nginx.org/r/internal

Cheers,

	f
-- 
Francis Daly        francis at daoine.org

From francis at daoine.org  Sun Feb 19 13:37:03 2023
From: francis at daoine.org (Francis Daly)
Date: Sun, 19 Feb 2023 13:37:03 +0000
Subject: FAQ Suggestions
In-Reply-To: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
Message-ID: <20230219133703.GE21799@daoine.org>

On Sat, Feb 18, 2023 at 05:27:45PM -0800, Ivo Welch wrote:

Hi there,

> 1. is this mailing list the correct place to suggest additions to the FAQ?

It's as good a place as any, yes.

> 2. why does
> 
> ```
> location /wth {
>    root /var/www/fcgi-bin/;
>    index wth-root.html;
>  }
> ```
> 
> not resolve '/wth' (but incidentally does resolve '/wth-root.html',
> though not '/wth-root').

What test makes you believe that "location /wth" does not resolve the
request "/wth", in your config?

> I have been scratching my head about this for the longest time.

What other location{}s are in this config, which you might have told
nginx to use instead of this one?

Can you show one example config that shows the problem?

For example, if I use:

```
server {
        listen 10080;
        root /tmp/r;
        location /wth {
                root /tmp/w;
                index w.html;
        }
}
```

then "curl http://localhost:10080/wth" redirects me to
http://localhost:10080/wth/; and "curl http://localhost:10080/wth/"
gets me the content of /tmp/w/wth/w.html.

Do you see or expect something different?

Thanks,

	f
-- 
Francis Daly        francis at daoine.org

From venefax at gmail.com  Sun Feb 19 14:33:46 2023
From: venefax at gmail.com (Saint Michael)
Date: Sun, 19 Feb 2023 09:33:46 -0500
Subject: Private location does not work
In-Reply-To: <20230219131948.GD21799@daoine.org>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
Message-ID: <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>

Dear Francis
it does not work:
404 Not Found

this is my code
location /asrxxxx {
default_type  'text/html; charset=UTF-8';
internal;
....

}

location /carrier_00163e1bb23c {
default_type  'text/html; charset=UTF-8';
....

}

in the public location,  /carrier_00163e1bb23c, I have
</div>
<iframe src="/asrxxxx">
    Your browser does not support iframes
</iframe>
</div>

so how do I block the public from looking at my HTML and executing directly
/asrxxxx?
Is this a bug?
many thanks for your help.
Philip







On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org> wrote:

> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>
> Hi there,
>
> > it fails with forbidden. But I am using only from another location inside
> > the same server.
> >
> > How do I protect internal service locations and at the same time use
> them?
>
> If you are asking "how do I ensure that a location{} can only be used for
> internal redirects/requests", then you want http://nginx.org/r/internal
>
> Cheers,
>
>         f
> --
> Francis Daly        francis at daoine.org
> _______________________________________________
> 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/20230219/f77afcd5/attachment.htm>

From ivo.welch at gmail.com  Mon Feb 20 01:49:48 2023
From: ivo.welch at gmail.com (Ivo Welch)
Date: Sun, 19 Feb 2023 17:49:48 -0800
Subject: FAQ Suggestions
In-Reply-To: <20230219133703.GE21799@daoine.org>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <20230219133703.GE21799@daoine.org>
Message-ID: <CACi4-JkWSU+7WMSYX_-RN_5NRa49kdhpiG8M_6h8YETg1DPBLw@mail.gmail.com>

thank you, F.  I created a completely new ubuntu VM, with a completely
vanilla configuration and only this one extra location statement at
http://164.67.176.22/  , describing the nginx configuration and
referencing its /wth, and it's not working :-( .

On Sun, Feb 19, 2023 at 5:37 AM Francis Daly <francis at daoine.org> wrote:
>
> On Sat, Feb 18, 2023 at 05:27:45PM -0800, Ivo Welch wrote:
>
> Hi there,
>
> > 1. is this mailing list the correct place to suggest additions to the FAQ?
>
> It's as good a place as any, yes.
>
> > 2. why does
> >
> > ```
> > location /wth {
> >    root /var/www/fcgi-bin/;
> >    index wth-root.html;
> >  }
> > ```
> >
> > not resolve '/wth' (but incidentally does resolve '/wth-root.html',
> > though not '/wth-root').
>
> What test makes you believe that "location /wth" does not resolve the
> request "/wth", in your config?
>
> > I have been scratching my head about this for the longest time.
>
> What other location{}s are in this config, which you might have told
> nginx to use instead of this one?
>
> Can you show one example config that shows the problem?
>
> For example, if I use:
>
> ```
> server {
>         listen 10080;
>         root /tmp/r;
>         location /wth {
>                 root /tmp/w;
>                 index w.html;
>         }
> }
> ```
>
> then "curl http://localhost:10080/wth" redirects me to
> http://localhost:10080/wth/; and "curl http://localhost:10080/wth/"
> gets me the content of /tmp/w/wth/w.html.
>
> Do you see or expect something different?
>
> Thanks,
>
>         f
> --
> Francis Daly        francis at daoine.org
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

From ivo.welch at gmail.com  Mon Feb 20 01:51:39 2023
From: ivo.welch at gmail.com (Ivo Welch)
Date: Sun, 19 Feb 2023 17:51:39 -0800
Subject: FAQ Suggestions
In-Reply-To: <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
Message-ID: <CACi4-JmG5ExyByMW17F9mRuS6YMyyZxooGP6du1BRDnatwAFnQ@mail.gmail.com>

please ignore previous email.  nanaya has an explanation that I need
to explore.  I think this would make a great example for an FAQ...

On Sat, Feb 18, 2023 at 10:27 PM nanaya <me at nanaya.net> wrote:
>
> Hi
>
> On Sun, Feb 19, 2023, at 10:27, Ivo Welch wrote:
> > 2. why does
> >
> > ```
> > location /wth {
> >    root /var/www/fcgi-bin/;
> >    index wth-root.html;
> >  }
> > ```
> >
> > not resolve '/wth' (but incidentally does resolve '/wth-root.html',
> > though not '/wth-root').
> >
>
> it's one of the common confusions. Just /wth doesn't trigger index listing as it doesn't end with a forward slash. /wth-root does match because /wth matches anything that starts with /wth (some people seem to think it matches /wth/ directory but it really doesn't - it's just prefix matching after all).
>
> If you have /var/www/fcgi-bin/wtha.html file and try accessing /wtha.html, it'll return that file, for example. Same with /wth-root.html as you experienced.
>
> Back to /wth, it'll try to return file /var/www/fcgi-bin/wth (which probably doesn't exist).
>
> If what you actually want is to to match /wth/, it needs to be `location /wth/`. Although then it can't be accessed through /wth as it doesn't match anymore (unless it exists as directory in other location like `location /`). In which case I usually add `location = /wth { return 302 /wth/; }` to fix this one special case.
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

From pchychi at gmail.com  Mon Feb 20 03:31:48 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Sun, 19 Feb 2023 19:31:48 -0800
Subject: Private location does not work
In-Reply-To: <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
Message-ID: <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>

You need to learn two things:
1- learn to read the page and understand what the expected result should be
2- google!

Your problem has been well covered thousands of times before.

Your 404 is expected error code when you are accessing the website from
external.

Also, read
https://nginx.org/en/docs/http/ngx_http_access_module.html




On Sun, Feb 19, 2023 at 6:34 AM Saint Michael <venefax at gmail.com> wrote:

> Dear Francis
> it does not work:
> 404 Not Found
>
> this is my code
> location /asrxxxx {
> default_type  'text/html; charset=UTF-8';
> internal;
> ....
>
> }
>
> location /carrier_00163e1bb23c {
> default_type  'text/html; charset=UTF-8';
> ....
>
> }
>
> in the public location,  /carrier_00163e1bb23c, I have
> </div>
> <iframe src="/asrxxxx">
>     Your browser does not support iframes
> </iframe>
> </div>
>
> so how do I block the public from looking at my HTML and executing
> directly /asrxxxx?
> Is this a bug?
> many thanks for your help.
> Philip
>
>
>
>
>
>
>
> On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org> wrote:
>
>> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>>
>> Hi there,
>>
>> > it fails with forbidden. But I am using only from another location
>> inside
>> > the same server.
>> >
>> > How do I protect internal service locations and at the same time use
>> them?
>>
>> If you are asking "how do I ensure that a location{} can only be used for
>> internal redirects/requests", then you want http://nginx.org/r/internal
>>
>> Cheers,
>>
>>         f
>> --
>> Francis Daly        francis at daoine.org
>> _______________________________________________
>> 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
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230219/46a9337d/attachment-0001.htm>

From venefax at gmail.com  Mon Feb 20 03:54:03 2023
From: venefax at gmail.com (Saint Michael)
Date: Sun, 19 Feb 2023 22:54:03 -0500
Subject: Private location does not work
In-Reply-To: <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>
Message-ID: <CAC9cSODXzf3nnahQHxvnzyToBSATi3sj85x8_iCQzd1mkqRGxA@mail.gmail.com>

I also tried

deny  192.168.1.1;
    allow 192.168.1.0/24;
    allow 10.1.1.0/16;
    allow 2001:0db8::/32;
    deny  all;


and it does not work. It uses the remote IP of the caller.


So Nginx does not have a way to do this.

Thanks doe confirming it.



On Sun, Feb 19, 2023 at 10:32 PM Payam Chychi <pchychi at gmail.com> wrote:

> You need to learn two things:
> 1- learn to read the page and understand what the expected result should be
> 2- google!
>
> Your problem has been well covered thousands of times before.
>
> Your 404 is expected error code when you are accessing the website from
> external.
>
> Also, read
> https://nginx.org/en/docs/http/ngx_http_access_module.html
>
>
>
>
> On Sun, Feb 19, 2023 at 6:34 AM Saint Michael <venefax at gmail.com> wrote:
>
>> Dear Francis
>> it does not work:
>> 404 Not Found
>>
>> this is my code
>> location /asrxxxx {
>> default_type  'text/html; charset=UTF-8';
>> internal;
>> ....
>>
>> }
>>
>> location /carrier_00163e1bb23c {
>> default_type  'text/html; charset=UTF-8';
>> ....
>>
>> }
>>
>> in the public location,  /carrier_00163e1bb23c, I have
>> </div>
>> <iframe src="/asrxxxx">
>>     Your browser does not support iframes
>> </iframe>
>> </div>
>>
>> so how do I block the public from looking at my HTML and executing
>> directly /asrxxxx?
>> Is this a bug?
>> many thanks for your help.
>> Philip
>>
>>
>>
>>
>>
>>
>>
>> On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org> wrote:
>>
>>> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>>>
>>> Hi there,
>>>
>>> > it fails with forbidden. But I am using only from another location
>>> inside
>>> > the same server.
>>> >
>>> > How do I protect internal service locations and at the same time use
>>> them?
>>>
>>> If you are asking "how do I ensure that a location{} can only be used for
>>> internal redirects/requests", then you want http://nginx.org/r/internal
>>>
>>> Cheers,
>>>
>>>         f
>>> --
>>> Francis Daly        francis at daoine.org
>>> _______________________________________________
>>> 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
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230219/8f4f2064/attachment.htm>

From pchychi at gmail.com  Mon Feb 20 03:59:48 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Sun, 19 Feb 2023 19:59:48 -0800
Subject: Private location does not work
In-Reply-To: <CAC9cSODXzf3nnahQHxvnzyToBSATi3sj85x8_iCQzd1mkqRGxA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>
 <CAC9cSODXzf3nnahQHxvnzyToBSATi3sj85x8_iCQzd1mkqRGxA@mail.gmail.com>
Message-ID: <CAJMkcM3p=OgzeVZKi=1xdP59G3f0r1sbfcNeB4O_e+uanBOB_Q@mail.gmail.com>

Yes it does, but you are not providing enough on what you are doing, only
what you want to do.

Run developer tools and see what your ip address is reported as.

On Sun, Feb 19, 2023 at 7:54 PM Saint Michael <venefax at gmail.com> wrote:

> I also tried
>
> deny  192.168.1.1;
>     allow 192.168.1.0/24;
>     allow 10.1.1.0/16;
>     allow 2001:0db8::/32;
>     deny  all;
>
>
> and it does not work. It uses the remote IP of the caller.
>
>
> So Nginx does not have a way to do this.
>
> Thanks doe confirming it.
>
>
>
> On Sun, Feb 19, 2023 at 10:32 PM Payam Chychi <pchychi at gmail.com> wrote:
>
>> You need to learn two things:
>> 1- learn to read the page and understand what the expected result should
>> be
>> 2- google!
>>
>> Your problem has been well covered thousands of times before.
>>
>> Your 404 is expected error code when you are accessing the website from
>> external.
>>
>> Also, read
>> https://nginx.org/en/docs/http/ngx_http_access_module.html
>>
>>
>>
>>
>> On Sun, Feb 19, 2023 at 6:34 AM Saint Michael <venefax at gmail.com> wrote:
>>
>>> Dear Francis
>>> it does not work:
>>> 404 Not Found
>>>
>>> this is my code
>>> location /asrxxxx {
>>> default_type  'text/html; charset=UTF-8';
>>> internal;
>>> ....
>>>
>>> }
>>>
>>> location /carrier_00163e1bb23c {
>>> default_type  'text/html; charset=UTF-8';
>>> ....
>>>
>>> }
>>>
>>> in the public location,  /carrier_00163e1bb23c, I have
>>> </div>
>>> <iframe src="/asrxxxx">
>>>     Your browser does not support iframes
>>> </iframe>
>>> </div>
>>>
>>> so how do I block the public from looking at my HTML and executing
>>> directly /asrxxxx?
>>> Is this a bug?
>>> many thanks for your help.
>>> Philip
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org> wrote:
>>>
>>>> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>>>>
>>>> Hi there,
>>>>
>>>> > it fails with forbidden. But I am using only from another location
>>>> inside
>>>> > the same server.
>>>> >
>>>> > How do I protect internal service locations and at the same time use
>>>> them?
>>>>
>>>> If you are asking "how do I ensure that a location{} can only be used
>>>> for
>>>> internal redirects/requests", then you want http://nginx.org/r/internal
>>>>
>>>> Cheers,
>>>>
>>>>         f
>>>> --
>>>> Francis Daly        francis at daoine.org
>>>> _______________________________________________
>>>> 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
>>>
>> --
>> Payam Tarverdyan Chychi
>> _______________________________________________
>> 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
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230219/570231e2/attachment.htm>

From venefax at gmail.com  Mon Feb 20 04:24:23 2023
From: venefax at gmail.com (Saint Michael)
Date: Sun, 19 Feb 2023 23:24:23 -0500
Subject: Private location does not work
In-Reply-To: <CAJMkcM3p=OgzeVZKi=1xdP59G3f0r1sbfcNeB4O_e+uanBOB_Q@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>
 <CAC9cSODXzf3nnahQHxvnzyToBSATi3sj85x8_iCQzd1mkqRGxA@mail.gmail.com>
 <CAJMkcM3p=OgzeVZKi=1xdP59G3f0r1sbfcNeB4O_e+uanBOB_Q@mail.gmail.com>
Message-ID: <CAC9cSOCz25=sNDXMPYCUA-vfxaUMHTJCe3mFVcDSAUTpF3N-qg@mail.gmail.com>

It uses the original IP of the user, not of the server.
That's why the ALLOW..DENY does not work either.
Nobody thought about this in Nginx.


On Sun, Feb 19, 2023 at 11:00 PM Payam Chychi <pchychi at gmail.com> wrote:

> Yes it does, but you are not providing enough on what you are doing, only
> what you want to do.
>
> Run developer tools and see what your ip address is reported as.
>
> On Sun, Feb 19, 2023 at 7:54 PM Saint Michael <venefax at gmail.com> wrote:
>
>> I also tried
>>
>> deny  192.168.1.1;
>>     allow 192.168.1.0/24;
>>     allow 10.1.1.0/16;
>>     allow 2001:0db8::/32;
>>     deny  all;
>>
>>
>> and it does not work. It uses the remote IP of the caller.
>>
>>
>> So Nginx does not have a way to do this.
>>
>> Thanks doe confirming it.
>>
>>
>>
>> On Sun, Feb 19, 2023 at 10:32 PM Payam Chychi <pchychi at gmail.com> wrote:
>>
>>> You need to learn two things:
>>> 1- learn to read the page and understand what the expected result should
>>> be
>>> 2- google!
>>>
>>> Your problem has been well covered thousands of times before.
>>>
>>> Your 404 is expected error code when you are accessing the website from
>>> external.
>>>
>>> Also, read
>>> https://nginx.org/en/docs/http/ngx_http_access_module.html
>>>
>>>
>>>
>>>
>>> On Sun, Feb 19, 2023 at 6:34 AM Saint Michael <venefax at gmail.com> wrote:
>>>
>>>> Dear Francis
>>>> it does not work:
>>>> 404 Not Found
>>>>
>>>> this is my code
>>>> location /asrxxxx {
>>>> default_type  'text/html; charset=UTF-8';
>>>> internal;
>>>> ....
>>>>
>>>> }
>>>>
>>>> location /carrier_00163e1bb23c {
>>>> default_type  'text/html; charset=UTF-8';
>>>> ....
>>>>
>>>> }
>>>>
>>>> in the public location,  /carrier_00163e1bb23c, I have
>>>> </div>
>>>> <iframe src="/asrxxxx">
>>>>     Your browser does not support iframes
>>>> </iframe>
>>>> </div>
>>>>
>>>> so how do I block the public from looking at my HTML and executing
>>>> directly /asrxxxx?
>>>> Is this a bug?
>>>> many thanks for your help.
>>>> Philip
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org>
>>>> wrote:
>>>>
>>>>> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>>>>>
>>>>> Hi there,
>>>>>
>>>>> > it fails with forbidden. But I am using only from another location
>>>>> inside
>>>>> > the same server.
>>>>> >
>>>>> > How do I protect internal service locations and at the same time use
>>>>> them?
>>>>>
>>>>> If you are asking "how do I ensure that a location{} can only be used
>>>>> for
>>>>> internal redirects/requests", then you want
>>>>> http://nginx.org/r/internal
>>>>>
>>>>> Cheers,
>>>>>
>>>>>         f
>>>>> --
>>>>> Francis Daly        francis at daoine.org
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> --
>>> Payam Tarverdyan Chychi
>>> _______________________________________________
>>> 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
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230219/537b5fc3/attachment-0001.htm>

From pchychi at gmail.com  Mon Feb 20 04:51:51 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Sun, 19 Feb 2023 20:51:51 -0800
Subject: Private location does not work
In-Reply-To: <CAC9cSOCz25=sNDXMPYCUA-vfxaUMHTJCe3mFVcDSAUTpF3N-qg@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>
 <CAC9cSODXzf3nnahQHxvnzyToBSATi3sj85x8_iCQzd1mkqRGxA@mail.gmail.com>
 <CAJMkcM3p=OgzeVZKi=1xdP59G3f0r1sbfcNeB4O_e+uanBOB_Q@mail.gmail.com>
 <CAC9cSOCz25=sNDXMPYCUA-vfxaUMHTJCe3mFVcDSAUTpF3N-qg@mail.gmail.com>
Message-ID: <CAJMkcM2R=txDUyrgTWWhRjQx+mzL4CTu_jF_P2U+x5OBesZJfA@mail.gmail.com>

You need to be more clear on what you are trying to do so we can help you.
Draw a diagram or something with the details.

You can use authentication and use that to protect and use at the same time
but again, you have left out some critical details as to what you are tying
to accomplish.

Nginx is powerful, you can write rules to do almost anything, but first you
need to figure out what you want to do.



On Sun, Feb 19, 2023 at 8:24 PM Saint Michael <venefax at gmail.com> wrote:

> It uses the original IP of the user, not of the server.
> That's why the ALLOW..DENY does not work either.
> Nobody thought about this in Nginx.
>
>
> On Sun, Feb 19, 2023 at 11:00 PM Payam Chychi <pchychi at gmail.com> wrote:
>
>> Yes it does, but you are not providing enough on what you are doing, only
>> what you want to do.
>>
>> Run developer tools and see what your ip address is reported as.
>>
>> On Sun, Feb 19, 2023 at 7:54 PM Saint Michael <venefax at gmail.com> wrote:
>>
>>> I also tried
>>>
>>> deny  192.168.1.1;
>>>     allow 192.168.1.0/24;
>>>     allow 10.1.1.0/16;
>>>     allow 2001:0db8::/32;
>>>     deny  all;
>>>
>>>
>>> and it does not work. It uses the remote IP of the caller.
>>>
>>>
>>> So Nginx does not have a way to do this.
>>>
>>> Thanks doe confirming it.
>>>
>>>
>>>
>>> On Sun, Feb 19, 2023 at 10:32 PM Payam Chychi <pchychi at gmail.com> wrote:
>>>
>>>> You need to learn two things:
>>>> 1- learn to read the page and understand what the expected result
>>>> should be
>>>> 2- google!
>>>>
>>>> Your problem has been well covered thousands of times before.
>>>>
>>>> Your 404 is expected error code when you are accessing the website from
>>>> external.
>>>>
>>>> Also, read
>>>> https://nginx.org/en/docs/http/ngx_http_access_module.html
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Feb 19, 2023 at 6:34 AM Saint Michael <venefax at gmail.com>
>>>> wrote:
>>>>
>>>>> Dear Francis
>>>>> it does not work:
>>>>> 404 Not Found
>>>>>
>>>>> this is my code
>>>>> location /asrxxxx {
>>>>> default_type  'text/html; charset=UTF-8';
>>>>> internal;
>>>>> ....
>>>>>
>>>>> }
>>>>>
>>>>> location /carrier_00163e1bb23c {
>>>>> default_type  'text/html; charset=UTF-8';
>>>>> ....
>>>>>
>>>>> }
>>>>>
>>>>> in the public location,  /carrier_00163e1bb23c, I have
>>>>> </div>
>>>>> <iframe src="/asrxxxx">
>>>>>     Your browser does not support iframes
>>>>> </iframe>
>>>>> </div>
>>>>>
>>>>> so how do I block the public from looking at my HTML and executing
>>>>> directly /asrxxxx?
>>>>> Is this a bug?
>>>>> many thanks for your help.
>>>>> Philip
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org>
>>>>> wrote:
>>>>>
>>>>>> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>>>>>>
>>>>>> Hi there,
>>>>>>
>>>>>> > it fails with forbidden. But I am using only from another location
>>>>>> inside
>>>>>> > the same server.
>>>>>> >
>>>>>> > How do I protect internal service locations and at the same time
>>>>>> use them?
>>>>>>
>>>>>> If you are asking "how do I ensure that a location{} can only be used
>>>>>> for
>>>>>> internal redirects/requests", then you want
>>>>>> http://nginx.org/r/internal
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>         f
>>>>>> --
>>>>>> Francis Daly        francis at daoine.org
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>> --
>>>> Payam Tarverdyan Chychi
>>>> _______________________________________________
>>>> 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
>>>
>> --
>> Payam Tarverdyan Chychi
>> _______________________________________________
>> 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
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230219/1e17bd63/attachment.htm>

From venefax at gmail.com  Mon Feb 20 05:04:50 2023
From: venefax at gmail.com (Saint Michael)
Date: Mon, 20 Feb 2023 00:04:50 -0500
Subject: Private location does not work
In-Reply-To: <CAJMkcM2R=txDUyrgTWWhRjQx+mzL4CTu_jF_P2U+x5OBesZJfA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <CAJMkcM20qgwpnNJat03v8AUCmsm81o6Pi_tGj8esBYyxfzTHxQ@mail.gmail.com>
 <CAC9cSODXzf3nnahQHxvnzyToBSATi3sj85x8_iCQzd1mkqRGxA@mail.gmail.com>
 <CAJMkcM3p=OgzeVZKi=1xdP59G3f0r1sbfcNeB4O_e+uanBOB_Q@mail.gmail.com>
 <CAC9cSOCz25=sNDXMPYCUA-vfxaUMHTJCe3mFVcDSAUTpF3N-qg@mail.gmail.com>
 <CAJMkcM2R=txDUyrgTWWhRjQx+mzL4CTu_jF_P2U+x5OBesZJfA@mail.gmail.com>
Message-ID: <CAC9cSOD08mhArkGm_A=k_eQC63cvi8FnFLMX3LWgOGg3aPgLQA@mail.gmail.com>

Thanks for your patience.
I publish a report, which takes 1 minute to complete.
So I send the users to a spinner, which has an Iframe inside.
While the spinner spins, the iframe runs the report from the /internal
location.
Once the report is ready, the spinner hides the div and replaces the
internal HTML with the one from the Iframe.
I haven't found any other way to display a spinner covering the whole
screen while I get the report underneath. Once the report shows some images
at the top, the spinner disappears, but then it takes a minute for the real
data to display.
Any ideas?

On Sun, Feb 19, 2023 at 11:52 PM Payam Chychi <pchychi at gmail.com> wrote:

> You need to be more clear on what you are trying to do so we can help you.
> Draw a diagram or something with the details.
>
> You can use authentication and use that to protect and use at the same
> time but again, you have left out some critical details as to what you are
> tying to accomplish.
>
> Nginx is powerful, you can write rules to do almost anything, but first
> you need to figure out what you want to do.
>
>
>
> On Sun, Feb 19, 2023 at 8:24 PM Saint Michael <venefax at gmail.com> wrote:
>
>> It uses the original IP of the user, not of the server.
>> That's why the ALLOW..DENY does not work either.
>> Nobody thought about this in Nginx.
>>
>>
>> On Sun, Feb 19, 2023 at 11:00 PM Payam Chychi <pchychi at gmail.com> wrote:
>>
>>> Yes it does, but you are not providing enough on what you are doing,
>>> only what you want to do.
>>>
>>> Run developer tools and see what your ip address is reported as.
>>>
>>> On Sun, Feb 19, 2023 at 7:54 PM Saint Michael <venefax at gmail.com> wrote:
>>>
>>>> I also tried
>>>>
>>>> deny  192.168.1.1;
>>>>     allow 192.168.1.0/24;
>>>>     allow 10.1.1.0/16;
>>>>     allow 2001:0db8::/32;
>>>>     deny  all;
>>>>
>>>>
>>>> and it does not work. It uses the remote IP of the caller.
>>>>
>>>>
>>>> So Nginx does not have a way to do this.
>>>>
>>>> Thanks doe confirming it.
>>>>
>>>>
>>>>
>>>> On Sun, Feb 19, 2023 at 10:32 PM Payam Chychi <pchychi at gmail.com>
>>>> wrote:
>>>>
>>>>> You need to learn two things:
>>>>> 1- learn to read the page and understand what the expected result
>>>>> should be
>>>>> 2- google!
>>>>>
>>>>> Your problem has been well covered thousands of times before.
>>>>>
>>>>> Your 404 is expected error code when you are accessing the website
>>>>> from external.
>>>>>
>>>>> Also, read
>>>>> https://nginx.org/en/docs/http/ngx_http_access_module.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 19, 2023 at 6:34 AM Saint Michael <venefax at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Dear Francis
>>>>>> it does not work:
>>>>>> 404 Not Found
>>>>>>
>>>>>> this is my code
>>>>>> location /asrxxxx {
>>>>>> default_type  'text/html; charset=UTF-8';
>>>>>> internal;
>>>>>> ....
>>>>>>
>>>>>> }
>>>>>>
>>>>>> location /carrier_00163e1bb23c {
>>>>>> default_type  'text/html; charset=UTF-8';
>>>>>> ....
>>>>>>
>>>>>> }
>>>>>>
>>>>>> in the public location,  /carrier_00163e1bb23c, I have
>>>>>> </div>
>>>>>> <iframe src="/asrxxxx">
>>>>>>     Your browser does not support iframes
>>>>>> </iframe>
>>>>>> </div>
>>>>>>
>>>>>> so how do I block the public from looking at my HTML and executing
>>>>>> directly /asrxxxx?
>>>>>> Is this a bug?
>>>>>> many thanks for your help.
>>>>>> Philip
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Feb 19, 2023 at 8:20 AM Francis Daly <francis at daoine.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On Sun, Feb 19, 2023 at 01:52:12AM -0500, Saint Michael wrote:
>>>>>>>
>>>>>>> Hi there,
>>>>>>>
>>>>>>> > it fails with forbidden. But I am using only from another location
>>>>>>> inside
>>>>>>> > the same server.
>>>>>>> >
>>>>>>> > How do I protect internal service locations and at the same time
>>>>>>> use them?
>>>>>>>
>>>>>>> If you are asking "how do I ensure that a location{} can only be
>>>>>>> used for
>>>>>>> internal redirects/requests", then you want
>>>>>>> http://nginx.org/r/internal
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>>         f
>>>>>>> --
>>>>>>> Francis Daly        francis at daoine.org
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>> --
>>>>> Payam Tarverdyan Chychi
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> --
>>> Payam Tarverdyan Chychi
>>> _______________________________________________
>>> 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
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230220/33e2d326/attachment-0001.htm>

From me at nanaya.net  Mon Feb 20 07:09:58 2023
From: me at nanaya.net (nanaya)
Date: Mon, 20 Feb 2023 16:09:58 +0900
Subject: FAQ Suggestions
In-Reply-To: <CACi4-JmG5ExyByMW17F9mRuS6YMyyZxooGP6du1BRDnatwAFnQ@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CACi4-JmG5ExyByMW17F9mRuS6YMyyZxooGP6du1BRDnatwAFnQ@mail.gmail.com>
Message-ID: <58bbdc21-0127-49f6-b7df-0a1233160f4e@app.fastmail.com>

Hi,

On Mon, Feb 20, 2023, at 10:51, Ivo Welch wrote:
> please ignore previous email.  nanaya has an explanation that I need
> to explore.  I think this would make a great example for an FAQ...
>

As explained by Francis, I forgot to mention the part that "root /tmp/w" in a "location /wth" means accessing /tmp/w/wth for /wth and if it's a directory - as it would usually be - it'll return redirect to /wth/ which will then check /tmp/w/wth/ for the index file.

If you want /wth/a.html to return content of /tmp/w/a.html instead of /tmp/w/wth/a.html, use alias instead of root (although there may be other complications when combined with fastcgi for example).

From francis at daoine.org  Mon Feb 20 12:07:55 2023
From: francis at daoine.org (Francis Daly)
Date: Mon, 20 Feb 2023 12:07:55 +0000
Subject: FAQ Suggestions
In-Reply-To: <CACi4-JkWSU+7WMSYX_-RN_5NRa49kdhpiG8M_6h8YETg1DPBLw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <20230219133703.GE21799@daoine.org>
 <CACi4-JkWSU+7WMSYX_-RN_5NRa49kdhpiG8M_6h8YETg1DPBLw@mail.gmail.com>
Message-ID: <20230220120755.GF21799@daoine.org>

On Sun, Feb 19, 2023 at 05:49:48PM -0800, Ivo Welch wrote:

Hi there,

> thank you, F.  I created a completely new ubuntu VM, with a completely
> vanilla configuration and only this one extra location statement at
> http://164.67.176.22/  , describing the nginx configuration and
> referencing its /wth, and it's not working :-( .

For the convenience of future searchers, it would be better to include
the content at that url in the mail directly.

In this particular case, I suspect that the key line is

> try /wth, which nginx should resolve to
> /var/www/fcgi-bin/wth-root.html. However, this causes a 404 error.

When you make the request to /wth and get the 404 response, what is
written in the nginx error log? That will tell you what nginx thought
that nginx was doing; if that does not match what you thought that nginx
should be doing, that might point at the problem.

I suspect that the issue is a misunderstanding of what "root" does --
http://nginx.org/r/root. That content also includes a link to "alias",
which might be what you want, depending on what you want to have happen.

Good luck with it,

	f
-- 
Francis Daly        francis at daoine.org

From arut at nginx.com  Mon Feb 20 12:19:12 2023
From: arut at nginx.com (Roman Arutyunyan)
Date: Mon, 20 Feb 2023 16:19:12 +0400
Subject: [quic] can't define more than one server
In-Reply-To: <79c55e27-b64f-a948-128f-fc1dfdb44112@huenig.name>
References: <79c55e27-b64f-a948-128f-fc1dfdb44112@huenig.name>
Message-ID: <63186CD9-50B7-4B20-9BCF-F5D6F1764F47@nginx.com>

Hi Jonas,

> On 15 Feb 2023, at 21:50, Jonas Hünig via nginx-devel <nginx-devel at nginx.org> wrote:
> 
> Hi, 
> 
> I installed the new prebuild nginx package with http/3 support. This works very well for one server block, but when I add the listen directives to a second server block I get this error on configtest:
> 
> nginx: [emerg] duplicate listen options for X.X.X.X:443 in /etc/nginx/sites-available/quic2.c-X.maxcluster.net/userdefined.conf.init:1
> nginx: configuration file /etc/nginx/nginx.conf test failed
> 
> 
> anyone has an idea about this?
> 

You probably duplicated all listen parameters in the second listen directive.
There are listen parameters which are not allowed to be duplicated,
particularly socket options like "bind", "reuseport" etc.
Normally you specify them in the first listen, and then reference them by address/port.

Also, please notice that nginx-devel at nginx.org <mailto:nginx-devel at nginx.org> is a mailing list for development questions.
You should send user questions to nginx at nginx.org <mailto:nginx at nginx.org> instead.

----
Roman Arutyunyan
arut at nginx.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230220/38c5e708/attachment.htm>

From francis at daoine.org  Mon Feb 20 12:35:02 2023
From: francis at daoine.org (Francis Daly)
Date: Mon, 20 Feb 2023 12:35:02 +0000
Subject: Private location does not work
In-Reply-To: <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
Message-ID: <20230220123502.GG21799@daoine.org>

On Sun, Feb 19, 2023 at 09:33:46AM -0500, Saint Michael wrote:

Hi there,

> it does not work:
> 404 Not Found

It appears that you are not asking "how do I ensure that a location{}
can only be used for internal redirects/requests".

> in the public location,  /carrier_00163e1bb23c, I have
> <iframe src="/asrxxxx">
>     Your browser does not support iframes
> </iframe>

> so how do I block the public from looking at my HTML and executing directly
> /asrxxxx?

You don't.

> Is this a bug?

It's a misunderstanding on your part of how the requests from the browser
to the server work.

Right now, your question is "how do I block people from accessing a
URL, while also allowing them to access the URL". And the answer is
"you can't, reliably".

The thing that you want to achieve, can't be achieved using the plan
that you are currently following.

In the tradition of "the XY problem": if you will describe the thing
that you want to achieve, instead of just a part of the current thing
that you are doing to attempt to achieve it, then it may be that someone
can suggest a way to achieve it.

I do see a later mail that has some more details; but on first glance
it seems to be describing your current solution, rather than the problem.

Cheers,

	f
-- 
Francis Daly        francis at daoine.org

From pchychi at gmail.com  Mon Feb 20 18:21:14 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Mon, 20 Feb 2023 10:21:14 -0800
Subject: Private location does not work
In-Reply-To: <20230220123502.GG21799@daoine.org>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
Message-ID: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>

+1 Francis

Saint, I wonder if this might satisfy your ask indirectly.

Assign a secondary ip address to a nic, and redirect to that ip for your
iframe processing.

Then you can apply a more specific ACL at host or nginx level to control
iframe reachability, or even use a ip address thats only reachable to your
internal users.

The more correct way of doing all of this is through secure user session
management with authentication and authorization.

Good luck
-Payam

On Mon, Feb 20, 2023 at 4:35 AM Francis Daly <francis at daoine.org> wrote:

> On Sun, Feb 19, 2023 at 09:33:46AM -0500, Saint Michael wrote:
>
> Hi there,
>
> > it does not work:
> > 404 Not Found
>
> It appears that you are not asking "how do I ensure that a location{}
> can only be used for internal redirects/requests".
>
> > in the public location,  /carrier_00163e1bb23c, I have
> > <iframe src="/asrxxxx">
> >     Your browser does not support iframes
> > </iframe>
>
> > so how do I block the public from looking at my HTML and executing
> directly
> > /asrxxxx?
>
> You don't.
>
> > Is this a bug?
>
> It's a misunderstanding on your part of how the requests from the browser
> to the server work.
>
> Right now, your question is "how do I block people from accessing a
> URL, while also allowing them to access the URL". And the answer is
> "you can't, reliably".
>
> The thing that you want to achieve, can't be achieved using the plan
> that you are currently following.
>
> In the tradition of "the XY problem": if you will describe the thing
> that you want to achieve, instead of just a part of the current thing
> that you are doing to attempt to achieve it, then it may be that someone
> can suggest a way to achieve it.
>
> I do see a later mail that has some more details; but on first glance
> it seems to be describing your current solution, rather than the problem.
>
> Cheers,
>
>         f
> --
> Francis Daly        francis at daoine.org
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230220/e02017ea/attachment.htm>

From venefax at gmail.com  Mon Feb 20 19:45:03 2023
From: venefax at gmail.com (Saint Michael)
Date: Mon, 20 Feb 2023 14:45:03 -0500
Subject: Private location does not work
In-Reply-To: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
Message-ID: <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>

Thanks.
I am considering the options.

On Mon, Feb 20, 2023 at 1:21 PM Payam Chychi <pchychi at gmail.com> wrote:

> +1 Francis
>
> Saint, I wonder if this might satisfy your ask indirectly.
>
> Assign a secondary ip address to a nic, and redirect to that ip for your
> iframe processing.
>
> Then you can apply a more specific ACL at host or nginx level to control
> iframe reachability, or even use a ip address thats only reachable to your
> internal users.
>
> The more correct way of doing all of this is through secure user session
> management with authentication and authorization.
>
> Good luck
> -Payam
>
> On Mon, Feb 20, 2023 at 4:35 AM Francis Daly <francis at daoine.org> wrote:
>
>> On Sun, Feb 19, 2023 at 09:33:46AM -0500, Saint Michael wrote:
>>
>> Hi there,
>>
>> > it does not work:
>> > 404 Not Found
>>
>> It appears that you are not asking "how do I ensure that a location{}
>> can only be used for internal redirects/requests".
>>
>> > in the public location,  /carrier_00163e1bb23c, I have
>> > <iframe src="/asrxxxx">
>> >     Your browser does not support iframes
>> > </iframe>
>>
>> > so how do I block the public from looking at my HTML and executing
>> directly
>> > /asrxxxx?
>>
>> You don't.
>>
>> > Is this a bug?
>>
>> It's a misunderstanding on your part of how the requests from the browser
>> to the server work.
>>
>> Right now, your question is "how do I block people from accessing a
>> URL, while also allowing them to access the URL". And the answer is
>> "you can't, reliably".
>>
>> The thing that you want to achieve, can't be achieved using the plan
>> that you are currently following.
>>
>> In the tradition of "the XY problem": if you will describe the thing
>> that you want to achieve, instead of just a part of the current thing
>> that you are doing to attempt to achieve it, then it may be that someone
>> can suggest a way to achieve it.
>>
>> I do see a later mail that has some more details; but on first glance
>> it seems to be describing your current solution, rather than the problem.
>>
>> Cheers,
>>
>>         f
>> --
>> Francis Daly        francis at daoine.org
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230220/5b6a294e/attachment-0001.htm>

From venefax at gmail.com  Tue Feb 21 07:23:27 2023
From: venefax at gmail.com (Saint Michael)
Date: Tue, 21 Feb 2023 02:23:27 -0500
Subject: foreach does not work
In-Reply-To: <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
Message-ID: <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>

I am using openresty
nginx -version
nginx version: openresty/1.21.4.1



>  foreach $domain in $server_name {
>>
>         ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem;
>         ssl_certificate_key /etc/letsencrypt/live/$domain/privkey.pem;
>     }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230221/f20995a3/attachment.htm>

From venefax at gmail.com  Tue Feb 21 07:25:23 2023
From: venefax at gmail.com (Saint Michael)
Date: Tue, 21 Feb 2023 02:25:23 -0500
Subject: foreach does not work
In-Reply-To: <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
Message-ID: <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>

The question is, how do I use the foreach construct  in the nginx
configuration file?

> I am using openresty
> nginx -version
> nginx version: openresty/1.21.4.1
> This fails:
>
>
>
>>  foreach $domain in $server_name {
>>>
>>         ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem;
>>         ssl_certificate_key /etc/letsencrypt/live/$domain/privkey.pem;
>>     }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230221/4301fa4d/attachment.htm>

From osa at freebsd.org.ru  Tue Feb 21 15:28:22 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Tue, 21 Feb 2023 18:28:22 +0300
Subject: foreach does not work
In-Reply-To: <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
Message-ID: <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>

Hi there,

On Tue, Feb 21, 2023 at 02:25:23AM -0500, Saint Michael wrote:
> The question is, how do I use the foreach construct  in the nginx
> configuration file?

There's no foreach directive in the nginx directives list, [1],
please take a look.

That's probably something openresty related, so it's better to
ask such a question in an appropriate mailing list.

Thank you.

References
1. https://nginx.org/en/docs/dirindex.html

-- 
Sergey A. Osokin

From venefax at gmail.com  Wed Feb 22 15:57:31 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 10:57:31 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
Message-ID: <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>

>
> I have a location

root /static/duc/Digital_Universal_Currency;
    # ... other directives ...
        location / {

 try_files /index.html =404;
}
you my see it directly
https://securedigitalcheck.com
The images don't work. No browser can see them.
if I download them directly with wget, they download, same size, but in
Windows they do not open with paint or with Chrome, the error message says
that they are "format unknown".
but if I download the image via SCP, directly, there is nothing wrong with
them.
so what is ningx doing?




>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/fdd77ae3/attachment.htm>

From ivo.welch at gmail.com  Wed Feb 22 17:44:42 2023
From: ivo.welch at gmail.com (Ivo Welch)
Date: Wed, 22 Feb 2023 09:44:42 -0800
Subject: FAQ Suggestions --- mapping to file, not folder?
In-Reply-To: <20230220120755.GF21799@daoine.org>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <20230219133703.GE21799@daoine.org>
 <CACi4-JkWSU+7WMSYX_-RN_5NRa49kdhpiG8M_6h8YETg1DPBLw@mail.gmail.com>
 <20230220120755.GF21799@daoine.org>
Message-ID: <CACi4-JmmwYTXViKxoRFjEBgbHhL0RWEwGEoH4oVfHnC71beDRw@mail.gmail.com>

I think my fundamental misunderstanding was that a `location` block in
the nginx configuration always maps to a directory (folder) in the
file system.  The root just identifies the default file.  (this also
means that the browser can then always look around for other files in
this directory, though they may be kept unreadable for security.)

I was trying to define one specific URL to map to one specific file in
the file system. Is this possible?  That is, is there a way to map one
specific URL to one specific file?

/iaw

On Mon, Feb 20, 2023 at 4:08 AM Francis Daly <francis at daoine.org> wrote:
>
> On Sun, Feb 19, 2023 at 05:49:48PM -0800, Ivo Welch wrote:
>
> Hi there,
>
> > thank you, F.  I created a completely new ubuntu VM, with a completely
> > vanilla configuration and only this one extra location statement at
> > http://164.67.176.22/  , describing the nginx configuration and
> > referencing its /wth, and it's not working :-( .
>
> For the convenience of future searchers, it would be better to include
> the content at that url in the mail directly.
>
> In this particular case, I suspect that the key line is
>
> > try /wth, which nginx should resolve to
> > /var/www/fcgi-bin/wth-root.html. However, this causes a 404 error.
>
> When you make the request to /wth and get the 404 response, what is
> written in the nginx error log? That will tell you what nginx thought
> that nginx was doing; if that does not match what you thought that nginx
> should be doing, that might point at the problem.
>
> I suspect that the issue is a misunderstanding of what "root" does --
> http://nginx.org/r/root. That content also includes a link to "alias",
> which might be what you want, depending on what you want to have happen.
>
> Good luck with it,
>
>         f
> --
> Francis Daly        francis at daoine.org
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

From osa at freebsd.org.ru  Wed Feb 22 18:04:07 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Wed, 22 Feb 2023 21:04:07 +0300
Subject: FAQ Suggestions --- mapping to file, not folder?
In-Reply-To: <CACi4-JmmwYTXViKxoRFjEBgbHhL0RWEwGEoH4oVfHnC71beDRw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <20230219133703.GE21799@daoine.org>
 <CACi4-JkWSU+7WMSYX_-RN_5NRa49kdhpiG8M_6h8YETg1DPBLw@mail.gmail.com>
 <20230220120755.GF21799@daoine.org>
 <CACi4-JmmwYTXViKxoRFjEBgbHhL0RWEwGEoH4oVfHnC71beDRw@mail.gmail.com>
Message-ID: <Y/ZZFxqm7u++lzqr@FreeBSD.org.ru>

Hi Ivo,

On Wed, Feb 22, 2023 at 09:44:42AM -0800, Ivo Welch wrote:
> I think my fundamental misunderstanding was that a `location` block in
> the nginx configuration always maps to a directory (folder) in the
> file system.  The root just identifies the default file.  (this also
> means that the browser can then always look around for other files in
> this directory, though they may be kept unreadable for security.)

The root directive's description, [1], provides details how the directive
works.  Would you mind to provide more details in case the documentation
is unclear in that place, thank you.

> I was trying to define one specific URL to map to one specific file in
> the file system. Is this possible?  That is, is there a way to map one
> specific URL to one specific file?

The alias directive [2] may help in some cases, so please take a look on
that directive and report back how does that work for you.

Thank you.

References
1. https://nginx.org/en/docs/http/ngx_http_core_module.html#root
2. https://nginx.org/en/docs/http/ngx_http_core_module.html#alias

-- 
Sergey A. Osokin

From venefax at gmail.com  Wed Feb 22 19:03:43 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 14:03:43 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
Message-ID: <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>

I found the solution here
https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle

On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:

> I have a location
>
> root /static/duc/Digital_Universal_Currency;
>     # ... other directives ...
>         location / {
>
>  try_files /index.html =404;
> }
> you my see it directly
> https://securedigitalcheck.com
> The images don't work. No browser can see them.
> if I download them directly with wget, they download, same size, but in
> Windows they do not open with paint or with Chrome, the error message says
> that they are "format unknown".
> but if I download the image via SCP, directly, there is nothing wrong with
> them.
> so what is ningx doing?
>
>
>
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/70be5445/attachment.htm>

From venefax at gmail.com  Wed Feb 22 19:05:21 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 14:05:21 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
Message-ID: <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>

I wonder if Nginx will ever fix this issue. It's a clear bug in the
product. I wasted two days of sleep on this issue.



On Wed, Feb 22, 2023 at 2:03 PM Saint Michael <venefax at gmail.com> wrote:

> I found the solution here
>
> https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
>
> On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:
>
>> I have a location
>>
>> root /static/duc/Digital_Universal_Currency;
>>     # ... other directives ...
>>         location / {
>>
>>  try_files /index.html =404;
>> }
>> you my see it directly
>> https://securedigitalcheck.com
>> The images don't work. No browser can see them.
>> if I download them directly with wget, they download, same size, but in
>> Windows they do not open with paint or with Chrome, the error message says
>> that they are "format unknown".
>> but if I download the image via SCP, directly, there is nothing wrong
>> with them.
>> so what is ningx doing?
>>
>>
>>
>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/fb3b9c3d/attachment-0001.htm>

From osa at freebsd.org.ru  Wed Feb 22 19:32:26 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Wed, 22 Feb 2023 22:32:26 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
References: <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
Message-ID: <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>

On Wed, Feb 22, 2023 at 02:05:21PM -0500, Saint Michael wrote:
> I wonder if Nginx will ever fix this issue. It's a clear bug in the
> product. I wasted two days of sleep on this issue.

>From your previous email you've reported you've found a solution, so
that seems like not a bug and probably a misconfiguration on your
side or misunderstading of the official documentation.

However, in case you want to fill that as a bug, please use the
following URL, [1] , to submit a bug report with full descrpition
of your case.

Thank you.

1. https://trac.nginx.org/nginx/

-- 
Sergey A. Osokin

From venefax at gmail.com  Wed Feb 22 19:46:29 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 14:46:29 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
References: <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
Message-ID: <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>

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.



On Wed, Feb 22, 2023 at 2:32 PM Sergey A. Osokin <osa at freebsd.org.ru> wrote:

> On Wed, Feb 22, 2023 at 02:05:21PM -0500, Saint Michael wrote:
> > I wonder if Nginx will ever fix this issue. It's a clear bug in the
> > product. I wasted two days of sleep on this issue.
>
> From your previous email you've reported you've found a solution, so
> that seems like not a bug and probably a misconfiguration on your
> side or misunderstading of the official documentation.
>
> However, in case you want to fill that as a bug, please use the
> following URL, [1] , to submit a bug report with full descrpition
> of your case.
>
> Thank you.
>
> 1. https://trac.nginx.org/nginx/
>
> --
> Sergey A. Osokin
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/86fa9130/attachment.htm>

From chris at cretaforce.gr  Wed Feb 22 20:04:34 2023
From: chris at cretaforce.gr (Christos Chatzaras)
Date: Wed, 22 Feb 2023 22:04:34 +0200
Subject: Nginx mail proxy and TLS connection to the real mail server
Message-ID: <CBE4439F-902F-4AD3-B269-70BD18475C82@cretaforce.gr>

Hello,

I setup a Nginx mail proxy and I would like mail clients to connect to it without TLS and then the Nginx proxy to connect to the real mail server using TLS.

Is this possible?

Kind regards,
Christos Chatzaras
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/2e9631f5/attachment.htm>

From francis at daoine.org  Wed Feb 22 21:22:17 2023
From: francis at daoine.org (Francis Daly)
Date: Wed, 22 Feb 2023 21:22:17 +0000
Subject: FAQ Suggestions --- mapping to file, not folder?
In-Reply-To: <CACi4-JmmwYTXViKxoRFjEBgbHhL0RWEwGEoH4oVfHnC71beDRw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <20230219133703.GE21799@daoine.org>
 <CACi4-JkWSU+7WMSYX_-RN_5NRa49kdhpiG8M_6h8YETg1DPBLw@mail.gmail.com>
 <20230220120755.GF21799@daoine.org>
 <CACi4-JmmwYTXViKxoRFjEBgbHhL0RWEwGEoH4oVfHnC71beDRw@mail.gmail.com>
Message-ID: <20230222212217.GA6170@daoine.org>

On Wed, Feb 22, 2023 at 09:44:42AM -0800, Ivo Welch wrote:

Hi there,

> I think my fundamental misunderstanding was that a `location` block in
> the nginx configuration always maps to a directory (folder) in the
> file system.

Yes, that's a misunderstanding.

The details at http://nginx.org/r/location might help clarify; but they
may be too terse for this.

> The root just identifies the default file. 

That's a misunderstanding too. http://nginx.org/r/root for details.

> (this also
> means that the browser can then always look around for other files in
> this directory, though they may be kept unreadable for security.)

I'm not sure how that relates to the previous lines. Yes, the browser
can request any url. The server can choose how to respond to each request.

> I was trying to define one specific URL to map to one specific file in
> the file system. Is this possible?  That is, is there a way to map one
> specific URL to one specific file?

	location = /this-url { alias /var/www/that-file.txt; }

Cheers,

	f
-- 
Francis Daly        francis at daoine.org

From osa at freebsd.org.ru  Wed Feb 22 21:35:30 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Thu, 23 Feb 2023 00:35:30 +0300
Subject: Nginx mail proxy and TLS connection to the real mail server
In-Reply-To: <CBE4439F-902F-4AD3-B269-70BD18475C82@cretaforce.gr>
References: <CBE4439F-902F-4AD3-B269-70BD18475C82@cretaforce.gr>
Message-ID: <Y/aKouF8x/zhIj7P@FreeBSD.org.ru>

Hi Christos,

On Wed, Feb 22, 2023 at 10:04:34PM +0200, Christos Chatzaras wrote:
> 
> I setup a Nginx mail proxy and I would like mail clients to
> connect to it without TLS and then the Nginx proxy to connect
> to the real mail server using TLS.
> 
> Is this possible?

Short answer is no.  The proxy_ssl_* family directives are available
for ngx_http_proxy and ngx_stream_proxy modules only.

-- 
Sergey A. Osokin

From chris at cretaforce.gr  Wed Feb 22 22:03:15 2023
From: chris at cretaforce.gr (Christos Chatzaras)
Date: Thu, 23 Feb 2023 00:03:15 +0200
Subject: Nginx mail proxy and TLS connection to the real mail server
In-Reply-To: <Y/aKouF8x/zhIj7P@FreeBSD.org.ru>
References: <CBE4439F-902F-4AD3-B269-70BD18475C82@cretaforce.gr>
 <Y/aKouF8x/zhIj7P@FreeBSD.org.ru>
Message-ID: <655D13B7-F87E-4718-8816-91BFB911E62B@cretaforce.gr>


> Short answer is no.  The proxy_ssl_* family directives are available
> for ngx_http_proxy and ngx_stream_proxy modules only.
> 
> -- 
> Sergey A. Osokin

Thank you for the reply. Finally I did it by combining the Nginx mail proxy with multiple Stunnels.

From osa at freebsd.org.ru  Wed Feb 22 22:13:42 2023
From: osa at freebsd.org.ru (Sergey A. Osokin)
Date: Thu, 23 Feb 2023 01:13:42 +0300
Subject: Nginx mail proxy and TLS connection to the real mail server
In-Reply-To: <655D13B7-F87E-4718-8816-91BFB911E62B@cretaforce.gr>
References: <CBE4439F-902F-4AD3-B269-70BD18475C82@cretaforce.gr>
 <Y/aKouF8x/zhIj7P@FreeBSD.org.ru>
 <655D13B7-F87E-4718-8816-91BFB911E62B@cretaforce.gr>
Message-ID: <Y/aTluMgOFhRma3m@FreeBSD.org.ru>

On Thu, Feb 23, 2023 at 12:03:15AM +0200, Christos Chatzaras wrote:
> 
> > Short answer is no.  The proxy_ssl_* family directives are available
> > for ngx_http_proxy and ngx_stream_proxy modules only.
> 
> Thank you for the reply. Finally I did it by combining the Nginx
> mail proxy with multiple Stunnels.

Thanks for sharing that, Christos.

-- 
Sergey A. Osokin

From ivo.welch at gmail.com  Wed Feb 22 22:39:36 2023
From: ivo.welch at gmail.com (Ivo Welch)
Date: Wed, 22 Feb 2023 14:39:36 -0800
Subject: Log Of Attempted Files
Message-ID: <CACi4-Jk5qJP5YSS-5Z4SnN4M6WHqv0Xu_miwrW+DymWNOY=tVA@mail.gmail.com>

dear nginx experts --- If I use an alias in my location, then
$realpath shows in my log file what file was actually served up.
Great.

How can I show in the access log file what file(s) nginx tried?  I do
not want the full rewrite engine in the debug log --- it contains way
too many things I do not understand and way too few things I do [or,
equivalently, I am just much too clueless].  I would ideally want just
to see something like

/var/www/html/index.html not found
/var/www/html/index.htm not found
/var/www/html/index-debian.htm OK

Short of this, what is the $variable name for the last file for the
log format in nginx?  pointer(s) appreciated.

From mdounin at mdounin.ru  Thu Feb 23 00:17:00 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Feb 2023 03:17:00 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
Message-ID: <Y/awfEtssSm1tCJd@mdounin.ru>

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/

From mdounin at mdounin.ru  Thu Feb 23 00:32:29 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Feb 2023 03:32:29 +0300
Subject: Log Of Attempted Files
In-Reply-To: <CACi4-Jk5qJP5YSS-5Z4SnN4M6WHqv0Xu_miwrW+DymWNOY=tVA@mail.gmail.com>
References: <CACi4-Jk5qJP5YSS-5Z4SnN4M6WHqv0Xu_miwrW+DymWNOY=tVA@mail.gmail.com>
Message-ID: <Y/a0HR2CJdgbnMHc@mdounin.ru>

Hello!

On Wed, Feb 22, 2023 at 02:39:36PM -0800, Ivo Welch wrote:

> dear nginx experts --- If I use an alias in my location, then
> $realpath shows in my log file what file was actually served up.
> Great.

There is no $realpath variable in nginx.

The $request_filename variable identifies the file being served 
(or going to be served) based on URI and root/alias directives in 
effect, see http://nginx.org/r/$request_filename.

> How can I show in the access log file what file(s) nginx tried?  I do
> not want the full rewrite engine in the debug log --- it contains way
> too many things I do not understand and way too few things I do [or,
> equivalently, I am just much too clueless].  I would ideally want just
> to see something like
> 
> /var/www/html/index.html not found
> /var/www/html/index.htm not found
> /var/www/html/index-debian.htm OK
> 
> Short of this, what is the $variable name for the last file for the
> log format in nginx?  pointer(s) appreciated.

I don't think it's possible to obtain such a list of files in a 
variable.

-- 
Maxim Dounin
http://mdounin.ru/

From venefax at gmail.com  Thu Feb 23 00:35:54 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 19:35:54 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/awfEtssSm1tCJd@mdounin.ru>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
Message-ID: <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>

a) The error does not have a single line.
b) restarting does not fix it
c) my nginx is no acting as proxy
d) it happened twice and both times I fixed it by turning gzip off,
restarting, and back on.
e) I also noticed that I requested the image file with wget, get a full
HTML file for the whole document, but named as if it were the image file.

wget https://x3x.us/index_files/image001.jpg
but `stat image001.jpg' showed it was the entire text HTML file.

http {
client_max_body_size 1500M;
    include       mime.types;
   # default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local]
"$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  logs/access.log  main;
    sendfile        on;
    tcp_nopush     on;
    tcp_nodelay     on;
gzip on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript
application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";
    #keepalive_timeout  0;
    keepalive_timeout  65;
 types_hash_max_size 2048;
proxy_headers_hash_max_size 1024;
proxy_headers_hash_bucket_size 128;
        #gzip  on;
    #    error_log  /var/log/nginx/error.log debug;

error_log /var/log/nginx/error.log error;
error_log /var/log/nginx/error.log crit;

        access_log  /var/log/nginx/access.log;

server {
        add_header Strict-Transport-Security "max-age=31536000;
includeSubDomains" always;
        default_type  'text/html; charset=UTF-8';
    listen 208.78.161.6:80;
    server_name x3x.us;

    # Redirect all domains to https://x3x.us
    if ($scheme != "https") {
        return 301 https://x3x.us$request_uri;
    }
}

server {
       add_header Strict-Transport-Security "max-age=31536000;
includeSubDomains" always;
        default_type  'text/html; charset=UTF-8';
    listen 208.78.161.6:443 ssl;
    server_name x3x.us;

    ssl_certificate /etc/letsencrypt/live/x3x.us/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/x3x.us/privkey.pem;

root /static/duc/;

        location / {

try_files $uri $uri/ /index.html;


}

} #server

} #http





On Wed, Feb 22, 2023 at 7:17 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Feb 22, 2023 at 02:46:29PM -0500, Saint Michael wrote:
>
> > It's not a misconfiguration, is a huge bug.
> > A wasted two days of sleep for something that is 100% a bug.
> > Please read here:
> >
> https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
> > He mentions the same exact problem and also he points to
> >
> https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
> > where the author says that Niginx will not fix it.
> > So he already tried he was rebuffed.
>
> The fun fact is that the referenced article doesn't state "will
> not fix", but rather "not a top priority".  Further, proper error
> propagation is available in nginx for about 10 years now, since
> 2013 (http://hg.nginx.org/nginx/rev/d3eab5e2df5f, nginx 1.5.3).
> Quoting CHANGES:
>
>     *) Change: now after receiving an incomplete response from a backend
>        server nginx tries to send an available part of the response to a
>        client, and then closes client connection.
>
> As long as nginx have an information about an error, it will
> preserve this information and propagate it to the client.
>
> Also note that it is only expected to make a difference if you are
> using nginx as a proxy, not to directly serve files.  And only in
> case of errors.  That is, if you are seeing the behaviour
> described, it might be a good idea to focus on the errors in the
> first place.
>
> I don't think it's anyhow related though, as switching gzip off
> and back on, as seems to be "the fix" described in the first link,
> is not going to help with anything.  The important part is likely
> "restarted the server", so I would rather assume that "the server"
> (not sure if it refers to nginx or the whole server) was using an
> incorrect configuration and/or was out of some resources, and
> restart fixed it.
>
> Summing the above, if you want to find out what goes wrong in your
> case - you may want to provide more details.  If you don't, nobody
> will be able to do it, unfortunately.
>
> The most basic thing I would recommend in the first place is to
> look into nginx error log, it is likely to contain important
> information if something goes wrong.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/45e0aaaa/attachment.htm>

From mdounin at mdounin.ru  Thu Feb 23 02:28:09 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Feb 2023 05:28:09 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
References: <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
Message-ID: <Y/bPOQzGrDJ5ChcT@mdounin.ru>

Hello!

On Wed, Feb 22, 2023 at 07:35:54PM -0500, Saint Michael wrote:

> a) The error does not have a single line.
> b) restarting does not fix it
> c) my nginx is no acting as proxy

So it's certainly unrelated to the article about proxying and 
error propagation you've previously linked.

> 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.

Your configuration contains:

  try_files $uri $uri/ /index.html;

so returning "/index.html" for all non-existing files is what 
nginx is configured to do.

Are you sure the file you are requesting actually exists?  Is the 
file system with these files local, or it's something distributed 
and/or some network filesystem?  Are files static, or generated 
and/or synced from somewhere?

You may want to try removing the "try_files" directive, so nginx 
will be able to properly respond with 404 on non-existing files, 
and will log errors with details about attempts to request them.  
Such errors will look like:

2023/02/23 05:16:25 [error] 80125#100117: *1 open() "/path/to/file" failed (2: No such file or directory), client: ...

This should help to identify exact files being requested, so 
you'll be able to check them manually, as will contain exact error 
code, so it will be possible to identify various permission 
issues.

Hope this helps.

-- 
Maxim Dounin
http://mdounin.ru/

From venefax at gmail.com  Thu Feb 23 02:31:43 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 21:31:43 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/bPOQzGrDJ5ChcT@mdounin.ru>
References: <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
Message-ID: <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>

how would this line look?
try_files $uri $uri/ /index.html;
and how do set I the error log to the max level for this particular server
{}?
I am not getting any errors in /var/log/nginx/error.log


On Wed, Feb 22, 2023 at 9:28 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Feb 22, 2023 at 07:35:54PM -0500, Saint Michael wrote:
>
> > a) The error does not have a single line.
> > b) restarting does not fix it
> > c) my nginx is no acting as proxy
>
> So it's certainly unrelated to the article about proxying and
> error propagation you've previously linked.
>
> > 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.
>
> Your configuration contains:
>
>   try_files $uri $uri/ /index.html;
>
> so returning "/index.html" for all non-existing files is what
> nginx is configured to do.
>
> Are you sure the file you are requesting actually exists?  Is the
> file system with these files local, or it's something distributed
> and/or some network filesystem?  Are files static, or generated
> and/or synced from somewhere?
>
> You may want to try removing the "try_files" directive, so nginx
> will be able to properly respond with 404 on non-existing files,
> and will log errors with details about attempts to request them.
> Such errors will look like:
>
> 2023/02/23 05:16:25 [error] 80125#100117: *1 open() "/path/to/file" failed
> (2: No such file or directory), client: ...
>
> This should help to identify exact files being requested, so
> you'll be able to check them manually, as will contain exact error
> code, so it will be possible to identify various permission
> issues.
>
> Hope this helps.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/f0b649f7/attachment-0001.htm>

From mdounin at mdounin.ru  Thu Feb 23 02:48:39 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Feb 2023 05:48:39 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
References: <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
 <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
Message-ID: <Y/bUB45A98/XtPgE@mdounin.ru>

Hello!

On Wed, Feb 22, 2023 at 09:31:43PM -0500, Saint Michael wrote:

> how would this line look?
> try_files $uri $uri/ /index.html;

You have to remove this line completely (or comment it out by 
using the "#" character at the start of the line).

> and how do set I the error log to the max level for this particular server
> {}?
> I am not getting any errors in /var/log/nginx/error.log

I would recommend configuring error_log at the global level only, 
not in individual servers.  Just keep error_log at the global 
level, outside of the http{} block, and remove any other error_log 
directives.

Using the level "info" is the most verbose mode you'll be able to 
obtain from non-debug nginx builds.  It is usually ok to run this 
in production for a long time, especially when you are trying to 
investigate some issues.  It is also immediately shows that 
logging is properly configured, as nginx will log some 
notice-level messages at start.

-- 
Maxim Dounin
http://mdounin.ru/

From venefax at gmail.com  Thu Feb 23 03:50:11 2023
From: venefax at gmail.com (Saint Michael)
Date: Wed, 22 Feb 2023 22:50:11 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/bUB45A98/XtPgE@mdounin.ru>
References: <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
 <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
 <Y/bUB45A98/XtPgE@mdounin.ru>
Message-ID: <CAC9cSODFTwhZ2cicKqAFTOvBcgMA5gX_d6+6-44BzP7fKxKFvA@mail.gmail.com>

Question:
if I don't have any like inside de
location / {}
how does nginx delivers an html file out of many possibly found in the root
for the location?


On Wed, Feb 22, 2023 at 9:48 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Wed, Feb 22, 2023 at 09:31:43PM -0500, Saint Michael wrote:
>
> > how would this line look?
> > try_files $uri $uri/ /index.html;
>
> You have to remove this line completely (or comment it out by
> using the "#" character at the start of the line).
>
> > and how do set I the error log to the max level for this particular
> server
> > {}?
> > I am not getting any errors in /var/log/nginx/error.log
>
> I would recommend configuring error_log at the global level only,
> not in individual servers.  Just keep error_log at the global
> level, outside of the http{} block, and remove any other error_log
> directives.
>
> Using the level "info" is the most verbose mode you'll be able to
> obtain from non-debug nginx builds.  It is usually ok to run this
> in production for a long time, especially when you are trying to
> investigate some issues.  It is also immediately shows that
> logging is properly configured, as nginx will log some
> notice-level messages at start.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/b1f6b5f6/attachment.htm>

From r at roze.lv  Thu Feb 23 11:32:06 2023
From: r at roze.lv (Reinis Rozitis)
Date: Thu, 23 Feb 2023 13:32:06 +0200
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSODFTwhZ2cicKqAFTOvBcgMA5gX_d6+6-44BzP7fKxKFvA@mail.gmail.com>
References: <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
 <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
 <Y/bUB45A98/XtPgE@mdounin.ru>
 <CAC9cSODFTwhZ2cicKqAFTOvBcgMA5gX_d6+6-44BzP7fKxKFvA@mail.gmail.com>
Message-ID: <000001d9477a$75fc9510$61f5bf30$@roze.lv>

> Question:
> if I don't have any like inside de 
> location / {}
> how does nginx delivers an html file out of many possibly found in the root for the location?

There is generally no need to specify location / { .. } if you don't provide any specific configuration or behavior for it.

Having just:

server { 
root /some/path;
}

is enough to serve (static) files.  


If there is a request to '/'  by default nginx will try to look  for (index.html http://nginx.org/en/docs/http/ngx_http_index_module.html#index or any other files in defined by that directive in given order.

rr

From mdounin at mdounin.ru  Thu Feb 23 13:02:48 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Feb 2023 16:02:48 +0300
Subject: nginx serving corrupt images
In-Reply-To: <000001d9477a$75fc9510$61f5bf30$@roze.lv>
References: <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
 <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
 <Y/bUB45A98/XtPgE@mdounin.ru>
 <CAC9cSODFTwhZ2cicKqAFTOvBcgMA5gX_d6+6-44BzP7fKxKFvA@mail.gmail.com>
 <000001d9477a$75fc9510$61f5bf30$@roze.lv>
Message-ID: <Y/dj+CBopwYHTmzj@mdounin.ru>

Hello!

On Thu, Feb 23, 2023 at 01:32:06PM +0200, Reinis Rozitis wrote:

> > Question:
> > if I don't have any like inside de 
> > location / {}
> > how does nginx delivers an html file out of many possibly found in the root for the location?
> 
> There is generally no need to specify location / { .. } if you don't provide any specific configuration or behavior for it.
> 
> Having just:
> 
> server { 
> root /some/path;
> }
> 
> is enough to serve (static) files.  

I would rather recommend to always specify at least "location /", 
even if it's empty.

While not specifying any locations mostly works, this causes nginx 
to process requests in the "server location", which was originally 
introduced as a purely technical one.  Trying to process requests 
in it might have various associated bugs.

-- 
Maxim Dounin
http://mdounin.ru/

From venefax at gmail.com  Thu Feb 23 13:13:54 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 08:13:54 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/dj+CBopwYHTmzj@mdounin.ru>
References: <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
 <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
 <Y/bUB45A98/XtPgE@mdounin.ru>
 <CAC9cSODFTwhZ2cicKqAFTOvBcgMA5gX_d6+6-44BzP7fKxKFvA@mail.gmail.com>
 <000001d9477a$75fc9510$61f5bf30$@roze.lv> <Y/dj+CBopwYHTmzj@mdounin.ru>
Message-ID: <CAC9cSOBWuVuNPUBtdfH1N+VwLY8YCZNLpZQv8+b2tAcUDn_6ag@mail.gmail.com>

Suppose that my default html file forn a location is xyz.html, but there
are hundreds. What is the canonical way to specify that and only that file
for a / {}.


On Thu, Feb 23, 2023, 8:03 AM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Thu, Feb 23, 2023 at 01:32:06PM +0200, Reinis Rozitis wrote:
>
> > > Question:
> > > if I don't have any like inside de
> > > location / {}
> > > how does nginx delivers an html file out of many possibly found in the
> root for the location?
> >
> > There is generally no need to specify location / { .. } if you don't
> provide any specific configuration or behavior for it.
> >
> > Having just:
> >
> > server {
> > root /some/path;
> > }
> >
> > is enough to serve (static) files.
>
> I would rather recommend to always specify at least "location /",
> even if it's empty.
>
> While not specifying any locations mostly works, this causes nginx
> to process requests in the "server location", which was originally
> introduced as a purely technical one.  Trying to process requests
> in it might have various associated bugs.
>
> --
> 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/f54f63c3/attachment.htm>

From mdounin at mdounin.ru  Thu Feb 23 14:17:26 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Thu, 23 Feb 2023 17:17:26 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOBWuVuNPUBtdfH1N+VwLY8YCZNLpZQv8+b2tAcUDn_6ag@mail.gmail.com>
References: <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <Y/bPOQzGrDJ5ChcT@mdounin.ru>
 <CAC9cSODPWM3zo2gJexyufTtdWruSYeuaLbt7=XkhQZMKEjJJfA@mail.gmail.com>
 <Y/bUB45A98/XtPgE@mdounin.ru>
 <CAC9cSODFTwhZ2cicKqAFTOvBcgMA5gX_d6+6-44BzP7fKxKFvA@mail.gmail.com>
 <000001d9477a$75fc9510$61f5bf30$@roze.lv>
 <Y/dj+CBopwYHTmzj@mdounin.ru>
 <CAC9cSOBWuVuNPUBtdfH1N+VwLY8YCZNLpZQv8+b2tAcUDn_6ag@mail.gmail.com>
Message-ID: <Y/d1dmUF8vlNLuyq@mdounin.ru>

Hello!

On Thu, Feb 23, 2023 at 08:13:54AM -0500, Saint Michael wrote:

> Suppose that my default html file forn a location is xyz.html, but there
> are hundreds. What is the canonical way to specify that and only that file
> for a / {}.

Locations are for a given URI prefix, not for a particular file.  
Locations define a configuration to be used for matching requests.  
See http://nginx.org/r/location for the detailed description of 
the location directive.

When mapping requests to the files, nginx simply concatenates the 
document root, as defined by the "root" directive, and URI from 
the requests.  For example, given "/path/to/html" root and a request 
to "/xyz.html", nginx will return the "/path/to/html/xyz.html" file.

If you want nginx to return only the particular file to all 
requests matched by the location, the most simple approach would 
be to use a rewrite (http://nginx.org/r/rewrite) to change the 
URI:

    location / {
        rewrite ^ /xyz.html break;
    }

Note though that this is not going to be a good solution to the 
issues with likely non-existing files you are facing.  Rather, 
this will make such issues impossible to debug, and is generally 
not recommended - unless you have good reasons to implement 
something like this.  Instead, I would recommend using normal 
request processing and let nginx to normally return files under 
the document root and reject requests to non-existing files.

Hope this helps.

-- 
Maxim Dounin
http://mdounin.ru/

From justdan23 at gmail.com  Thu Feb 23 23:15:47 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 18:15:47 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
Message-ID: <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>

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>

From justdan23 at gmail.com  Thu Feb 23 23:22:28 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 18:22:28 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
Message-ID: <CABFgU_jSNGvSs=NQAeNPrGH+0-bPtUvwgOZ_3=pSS9g92mTFQw@mail.gmail.com>

I don't see the rest of your nginx.conf.  Also, the link you posted is to a
logon page with no image URLs.

On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:

> I have a location
>
> root /static/duc/Digital_Universal_Currency;
>     # ... other directives ...
>         location / {
>
>  try_files /index.html =404;
> }
> you my see it directly
> https://securedigitalcheck.com
> The images don't work. No browser can see them.
> if I download them directly with wget, they download, same size, but in
> Windows they do not open with paint or with Chrome, the error message says
> that they are "format unknown".
> but if I download the image via SCP, directly, there is nothing wrong with
> them.
> so what is ningx doing?
>
>
>
>
>>
>> _______________________________________________
> 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/b65badda/attachment.htm>

From venefax at gmail.com  Thu Feb 23 23:32:11 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 18:32:11 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_jSNGvSs=NQAeNPrGH+0-bPtUvwgOZ_3=pSS9g92mTFQw@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CABFgU_jSNGvSs=NQAeNPrGH+0-bPtUvwgOZ_3=pSS9g92mTFQw@mail.gmail.com>
Message-ID: <CAC9cSOCM1Q93tinyOSJKdJfhM5qv+3PEBvhPjpC9z9Jtr84NtA@mail.gmail.com>

if I do this,
root /static/duc/;

        location / {

rewrite ^ /index.html break;
#try_files $uri $uri/ /index.html;
# try_files /index.html =404;

}
and open https://x3x.us/
the images cannot be seen, it does not work. Kindly test,
So, is there a way to specify the document for a location, if there are
many documents in the same root?
It looks like a big bug or misdesign to me.
Please don't believe me, I can send you the data and you may test it in
your own box.
or I can go back and then  you can pull the HTML and the two images with
curl



On Thu, Feb 23, 2023 at 6:22 PM Dan Swaney <justdan23 at gmail.com> wrote:

> I don't see the rest of your nginx.conf.  Also, the link you posted is to
> a logon page with no image URLs.
>
> On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:
>
>> I have a location
>>
>> root /static/duc/Digital_Universal_Currency;
>>     # ... other directives ...
>>         location / {
>>
>>  try_files /index.html =404;
>> }
>> you my see it directly
>> https://securedigitalcheck.com
>> The images don't work. No browser can see them.
>> if I download them directly with wget, they download, same size, but in
>> Windows they do not open with paint or with Chrome, the error message says
>> that they are "format unknown".
>> but if I download the image via SCP, directly, there is nothing wrong
>> with them.
>> so what is ningx doing?
>>
>>
>>
>>
>>>
>>> _______________________________________________
>> 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/264ea291/attachment.htm>

From venefax at gmail.com  Thu Feb 23 23:35:36 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 18:35:36 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOCM1Q93tinyOSJKdJfhM5qv+3PEBvhPjpC9z9Jtr84NtA@mail.gmail.com>
References: <CACi4-J=qHi1O4K_+vNUYMVOQ_eDjymkhz8bW+7qdw=ojGYTmXw@mail.gmail.com>
 <52fd6b3b-7218-468c-9b1c-b53c67b7ef9b@app.fastmail.com>
 <CAC9cSODgf6Y09UF4SnY_z=k9QNDhhXvzY=1p9w9oDKqRgPJoQA@mail.gmail.com>
 <20230219131948.GD21799@daoine.org>
 <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CABFgU_jSNGvSs=NQAeNPrGH+0-bPtUvwgOZ_3=pSS9g92mTFQw@mail.gmail.com>
 <CAC9cSOCM1Q93tinyOSJKdJfhM5qv+3PEBvhPjpC9z9Jtr84NtA@mail.gmail.com>
Message-ID: <CAC9cSODV3p7NOvKNrfgfw00h_UejQQe7eQMqQHgtfRWGkHwqDA@mail.gmail.com>

there is no error log, all I get is 023/02/23 23:33:56 [notice] 168280#0:
start worker process 168400
but my settings are
error_log  /var/log/nginx/error.log  info;



On Thu, Feb 23, 2023 at 6:32 PM Saint Michael <venefax at gmail.com> wrote:

> if I do this,
> root /static/duc/;
>
>         location / {
>
> rewrite ^ /index.html break;
> #try_files $uri $uri/ /index.html;
> # try_files /index.html =404;
>
> }
> and open https://x3x.us/
> the images cannot be seen, it does not work. Kindly test,
> So, is there a way to specify the document for a location, if there are
> many documents in the same root?
> It looks like a big bug or misdesign to me.
> Please don't believe me, I can send you the data and you may test it in
> your own box.
> or I can go back and then  you can pull the HTML and the two images with
> curl
>
>
>
> On Thu, Feb 23, 2023 at 6:22 PM Dan Swaney <justdan23 at gmail.com> wrote:
>
>> I don't see the rest of your nginx.conf.  Also, the link you posted is to
>> a logon page with no image URLs.
>>
>> On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:
>>
>>> I have a location
>>>
>>> root /static/duc/Digital_Universal_Currency;
>>>     # ... other directives ...
>>>         location / {
>>>
>>>  try_files /index.html =404;
>>> }
>>> you my see it directly
>>> https://securedigitalcheck.com
>>> The images don't work. No browser can see them.
>>> if I download them directly with wget, they download, same size, but in
>>> Windows they do not open with paint or with Chrome, the error message says
>>> that they are "format unknown".
>>> but if I download the image via SCP, directly, there is nothing wrong
>>> with them.
>>> so what is ningx doing?
>>>
>>>
>>>
>>>
>>>>
>>>> _______________________________________________
>>> 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/3315d5fd/attachment-0001.htm>

From justdan23 at gmail.com  Fri Feb 24 00:07:58 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 19:07:58 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
Message-ID: <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>

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>

From venefax at gmail.com  Fri Feb 24 00:21:44 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 19:21:44 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
Message-ID: <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/025f00af/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/025f00af/attachment-0003.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/025f00af/attachment-0004.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/025f00af/attachment-0005.png>

From justdan23 at gmail.com  Fri Feb 24 01:09:53 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 20:09:53 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
Message-ID: <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/7c2c8b91/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/7c2c8b91/attachment-0003.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/7c2c8b91/attachment-0004.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/7c2c8b91/attachment-0005.png>

From venefax at gmail.com  Fri Feb 24 02:27:33 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 21:27:33 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
Message-ID: <CAC9cSOBzdef8GNHVs=ashfu8xVtcb_N6y2mbAsvsLWHBLqfZSw@mail.gmail.com>

The error comes and goes, but there is no error in the logs.
You may test now the error.
do you have an idea what am I doing wrong?
grep -v "start\|exit\|grace" /usr/local/openresty/nginx/logs/error.log |
tail -20
2023/02/24 01:35:21 [notice] 172418#0: OS: Linux 6.1.10-1-pve
2023/02/24 01:35:21 [notice] 172418#0: getrlimit(RLIMIT_NOFILE):
1000000:1000000
2023/02/24 01:36:33 [notice] 172419#0: signal 3 (SIGQUIT) received from
172603, shutting down
2023/02/24 01:36:33 [notice] 172419#0: signal 17 (SIGCHLD) received from
172513
2023/02/24 01:36:33 [notice] 172419#0: signal 29 (SIGIO) received
2023/02/24 01:36:33 [notice] 172419#0: signal 17 (SIGCHLD) received from
172536
2023/02/24 01:36:33 [notice] 172419#0: signal 29 (SIGIO) received
2023/02/24 01:36:33 [notice] 172419#0: signal 17 (SIGCHLD) received from
172445
2023/02/24 01:36:33 [notice] 172419#0: signal 29 (SIGIO) received
2023/02/24 01:36:33 [notice] 172419#0: signal 17 (SIGCHLD) received from
172481
2023/02/24 01:36:33 [notice] 172419#0: signal 29 (SIGIO) received
2023/02/24 01:36:33 [notice] 172419#0: signal 17 (SIGCHLD) received from
172442
2023/02/24 01:36:35 [notice] 172609#0: using the "epoll" event method
2023/02/24 01:36:35 [notice] 172609#0: openresty/1.21.4.1
2023/02/24 01:36:35 [notice] 172609#0: built by gcc 11.3.0 (Ubuntu
11.3.0-1ubuntu1~22.04)
2023/02/24 01:36:35 [notice] 172609#0: OS: Linux 6.1.10-1-pve
2023/02/24 01:36:35 [notice] 172609#0: getrlimit(RLIMIT_NOFILE):
1000000:1000000
2023/02/24 02:22:04 [notice] 172653#0: signal 17 (SIGCHLD) received from
173309
2023/02/24 02:22:06 [notice] 172674#0: signal 17 (SIGCHLD) received from
173352
2023/02/24 02:22:09 [notice] 172693#0: signal 17 (SIGCHLD) received from
173395


On Thu, Feb 23, 2023 at 8:10 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/b309170f/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/b309170f/attachment-0003.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/b309170f/attachment-0004.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/b309170f/attachment-0005.png>

From justdan23 at gmail.com  Fri Feb 24 02:32:54 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 21:32:54 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
Message-ID: <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/059682db/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/059682db/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/059682db/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/059682db/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/059682db/attachment-0007.png>

From venefax at gmail.com  Fri Feb 24 02:42:23 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 21:42:23 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
Message-ID: <CAC9cSODEFyAP6B3Nz1gNRJeVKyz81jnQP=W=cwRQdTH9_1wT+Q@mail.gmail.com>

ok, so I am not insane. Is good to know.
23/02/24 02:38:44 [notice] 174292#0: using the "epoll" event method
2023/02/24 02:38:44 [notice] 174292#0: openresty/1.21.4.1
2023/02/24 02:38:44 [notice] 174292#0: built by gcc 11.3.0 (Ubuntu
11.3.0-1ubuntu1~22.04)
2023/02/24 02:38:44 [notice] 174292#0: OS: Linux 6.1.10-1-pve
2023/02/24 02:38:44 [notice] 174292#0: getrlimit(RLIMIT_NOFILE):
1000000:1000000

can you please file a bug? They would not talk to me because  I am a newbie.

Yours
Federico




On Thu, Feb 23, 2023 at 9:33 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/f1983996/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/f1983996/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/f1983996/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/f1983996/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/f1983996/attachment-0007.png>

From justdan23 at gmail.com  Fri Feb 24 02:42:29 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 21:42:29 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
Message-ID: <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/5d0aef19/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/5d0aef19/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/5d0aef19/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/5d0aef19/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/5d0aef19/attachment-0007.png>

From mdounin at mdounin.ru  Fri Feb 24 02:43:04 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 24 Feb 2023 05:43:04 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOCM1Q93tinyOSJKdJfhM5qv+3PEBvhPjpC9z9Jtr84NtA@mail.gmail.com>
References: <CAC9cSOAMbiGzdf0E3VwuGzE9cEVSpwLek33JNt+CJuoQqnNqzw@mail.gmail.com>
 <20230220123502.GG21799@daoine.org>
 <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CABFgU_jSNGvSs=NQAeNPrGH+0-bPtUvwgOZ_3=pSS9g92mTFQw@mail.gmail.com>
 <CAC9cSOCM1Q93tinyOSJKdJfhM5qv+3PEBvhPjpC9z9Jtr84NtA@mail.gmail.com>
Message-ID: <Y/gkONc3Sgixqi8e@mdounin.ru>

Hello!

On Thu, Feb 23, 2023 at 06:32:11PM -0500, Saint Michael wrote:

> if I do this,
> root /static/duc/;
> 
>         location / {
> 
> rewrite ^ /index.html break;
> #try_files $uri $uri/ /index.html;
> # try_files /index.html =404;
> 
> }
> and open https://x3x.us/
> the images cannot be seen, it does not work.

You've asked nginx to return index.html to all requests, and 
that's what it does.  Obviously enough, index.html is not an 
image, so no images are expected to be accessible.

As previously suggested, just remove anything from "location /", 
and let nginx do it's job.

[...]

-- 
Maxim Dounin
http://mdounin.ru/

From venefax at gmail.com  Fri Feb 24 02:47:01 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 21:47:01 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSODEFyAP6B3Nz1gNRJeVKyz81jnQP=W=cwRQdTH9_1wT+Q@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CAC9cSODEFyAP6B3Nz1gNRJeVKyz81jnQP=W=cwRQdTH9_1wT+Q@mail.gmail.com>
Message-ID: <CAC9cSODqwm++JRj8apZRLJD+-ZZ9W_jrj7P9JSnEaQK2jxeZ2A@mail.gmail.com>

You have the root inside the location:
location / {
            root   html;

I had it outside

root static/duc/;

        location / {

What is the correct way to do this?



On Thu, Feb 23, 2023 at 9:42 PM Saint Michael <venefax at gmail.com> wrote:

> ok, so I am not insane. Is good to know.
> 23/02/24 02:38:44 [notice] 174292#0: using the "epoll" event method
> 2023/02/24 02:38:44 [notice] 174292#0: openresty/1.21.4.1
> 2023/02/24 02:38:44 [notice] 174292#0: built by gcc 11.3.0 (Ubuntu
> 11.3.0-1ubuntu1~22.04)
> 2023/02/24 02:38:44 [notice] 174292#0: OS: Linux 6.1.10-1-pve
> 2023/02/24 02:38:44 [notice] 174292#0: getrlimit(RLIMIT_NOFILE):
> 1000000:1000000
>
> can you please file a bug? They would not talk to me because  I am a
> newbie.
>
> Yours
> Federico
>
>
>
>
> On Thu, Feb 23, 2023 at 9:33 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/8f3c3cd0/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/8f3c3cd0/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/8f3c3cd0/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/8f3c3cd0/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/8f3c3cd0/attachment-0007.png>

From venefax at gmail.com  Fri Feb 24 03:05:57 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 22:05:57 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
Message-ID: <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/426cb0ea/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/426cb0ea/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/426cb0ea/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/426cb0ea/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/426cb0ea/attachment-0007.png>

From justdan23 at gmail.com  Fri Feb 24 03:12:55 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 22:12:55 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
Message-ID: <CABFgU_g=W5KNOaiFy4JjvXfe8v778EBJbj9P=A4CkTZVPwEwvA@mail.gmail.com>

See my earlier response above for details.  It works when you reduce the
ssl_buffer_size to 4k.  You can try 8k for performance.

location / {
   ...
   ssl_buffer_size 4k;
}

Reference to setting is on this page:

https://haydenjames.io/nginx-tuning-tips-tls-ssl-https-ttfb-latency/

/

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/ace6f9cc/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/ace6f9cc/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/ace6f9cc/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/ace6f9cc/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/ace6f9cc/attachment-0007.png>

From justdan23 at gmail.com  Fri Feb 24 03:17:03 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 22:17:03 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
Message-ID: <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/d4a1018c/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/d4a1018c/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/d4a1018c/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/d4a1018c/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/d4a1018c/attachment-0007.png>

From venefax at gmail.com  Fri Feb 24 03:25:36 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 22:25:36 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
 <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
Message-ID: <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/27da2473/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/27da2473/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/27da2473/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/27da2473/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/27da2473/attachment-0007.png>

From mdounin at mdounin.ru  Fri Feb 24 03:26:38 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 24 Feb 2023 06:26:38 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
References: <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
Message-ID: <Y/gubnF79FGF7M4v@mdounin.ru>

Hello!

On Thu, Feb 23, 2023 at 09:42:29PM -0500, Dan Swaney wrote:

> Ah-ah...I caught the NGINX failure in the SSL response:

[...]

> > 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/>"*

The error suggests there is a bug in the SSL library you are 
using.  What does "nginx -V" show?

(IIRC, there was something like this in the OpenSSL development 
recently, though I believe it doesn't affect any of the released 
versions.  I may be wrong though.)

-- 
Maxim Dounin
http://mdounin.ru/

From justdan23 at gmail.com  Fri Feb 24 03:29:42 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 22:29:42 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
 <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
 <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
Message-ID: <CABFgU_g-NcyT0KLtnaDRFkwgBu0m3aH7yuxtdMmcNpBZ_=sTzw@mail.gmail.com>

Yes,  It works at the 'http' level:

http {

...

    ssl_buffer_size 4k;

}


I just tested it and it works with gzip on using your gzip settings.

On Thu, Feb 23, 2023 at 10:26 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/23d74646/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/23d74646/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/23d74646/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/23d74646/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/23d74646/attachment-0007.png>

From venefax at gmail.com  Fri Feb 24 03:29:50 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 22:29:50 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
 <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
 <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
Message-ID: <CAC9cSOBcc9efn9FO1-0SLMb1n5GEgPLyC=pKqiOGkezJgd+RTg@mail.gmail.com>

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/5fd68ad8/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/5fd68ad8/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/5fd68ad8/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/5fd68ad8/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/5fd68ad8/attachment-0007.png>

From justdan23 at gmail.com  Fri Feb 24 03:35:16 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 22:35:16 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/gubnF79FGF7M4v@mdounin.ru>
References: <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <Y/gubnF79FGF7M4v@mdounin.ru>
Message-ID: <CABFgU_gjMvRet5kCVQTH--Ww2tmBS5oyjgzuayVj2V6=x2=6jA@mail.gmail.com>

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
Saint's issue and discovered the work-around with lowering the
ssl_buffer_size to 4k,  Something for Saint to try out.

On Thu, Feb 23, 2023 at 10:26 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Thu, Feb 23, 2023 at 09:42:29PM -0500, Dan Swaney wrote:
>
> > Ah-ah...I caught the NGINX failure in the SSL response:
>
> [...]
>
> > > 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/>"*
>
> The error suggests there is a bug in the SSL library you are
> using.  What does "nginx -V" show?
>
> (IIRC, there was something like this in the OpenSSL development
> recently, though I believe it doesn't affect any of the released
> versions.  I may be wrong though.)
>
> --
> 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/2ad005f1/attachment.htm>

From justdan23 at gmail.com  Fri Feb 24 03:41:31 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 22:41:31 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSOBcc9efn9FO1-0SLMb1n5GEgPLyC=pKqiOGkezJgd+RTg@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
 <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
 <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
 <CAC9cSOBcc9efn9FO1-0SLMb1n5GEgPLyC=pKqiOGkezJgd+RTg@mail.gmail.com>
Message-ID: <CABFgU_gJfjxRcWG4rbxbwe7EKT1Fs62nPOFr=B_2NsbuNmVXLQ@mail.gmail.com>

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>

From justdan23 at gmail.com  Fri Feb 24 03:42:55 2023
From: justdan23 at gmail.com (Dan Swaney)
Date: Thu, 23 Feb 2023 22:42:55 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_gJfjxRcWG4rbxbwe7EKT1Fs62nPOFr=B_2NsbuNmVXLQ@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
 <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
 <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
 <CAC9cSOBcc9efn9FO1-0SLMb1n5GEgPLyC=pKqiOGkezJgd+RTg@mail.gmail.com>
 <CABFgU_gJfjxRcWG4rbxbwe7EKT1Fs62nPOFr=B_2NsbuNmVXLQ@mail.gmail.com>
Message-ID: <CABFgU_jJrRXDz2hgb95Znkr6Tict9t9CZBAffrE_zqChajqEvQ@mail.gmail.com>

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>

From venefax at gmail.com  Fri Feb 24 03:45:51 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 22:45:51 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_jJrRXDz2hgb95Znkr6Tict9t9CZBAffrE_zqChajqEvQ@mail.gmail.com>
References: <CAJMkcM0+qy86UMAne3d_tyouKt5WKNOtqGZm=ieRYxVAyjK3Pg@mail.gmail.com>
 <CAC9cSOCeEFCpY9Dscvib=gZrTHONPUZOeXuMRwin0Xch6dqkWA@mail.gmail.com>
 <CAC9cSODXeaoaJ=65z+uzBbJ6f0B0FUQoOAxxysBgyNU+tXoOLw@mail.gmail.com>
 <CAC9cSOBsG=yp1Z4Odd9BD2FVRJ78r=dRY=z2nr5Dy3MYfhq2CQ@mail.gmail.com>
 <Y/TjFmUpdfjyx8nt@FreeBSD.org.ru>
 <CAC9cSOCErn4yVmtKsceQ1Mqv_8uiOh3FZH5+3yawB+dRHi5YRA@mail.gmail.com>
 <CAC9cSOAEFOyaxuZ+tq-XKpCwQxuWBdQq4JVX1_54XL6AcyuBwg@mail.gmail.com>
 <CAC9cSOB7jiD8sdpGKn9=Zwad+1bR2E9NkATQVie3g0tXVJ9vKQ@mail.gmail.com>
 <Y/ZtyisOWJcBHJfn@FreeBSD.org.ru>
 <CAC9cSOAJFCihVYEJTNjQsien4foP1N9JtcAyuomzxGTRp3t=MA@mail.gmail.com>
 <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <CAC9cSOBerPMG=RVpxpa6i953OWkeE_n_2eY6FcY4ib_9F+MAUA@mail.gmail.com>
 <CABFgU_iU9RjqjBVut5V39B7Zy9YuRSibSMou7VdMRu_4DtZqEg@mail.gmail.com>
 <CAC9cSOBCK0HbYteDSuPPgsYM1DCaS4TSW8S9fbTkoFwzNYq-Lw@mail.gmail.com>
 <CAC9cSOBcc9efn9FO1-0SLMb1n5GEgPLyC=pKqiOGkezJgd+RTg@mail.gmail.com>
 <CABFgU_gJfjxRcWG4rbxbwe7EKT1Fs62nPOFr=B_2NsbuNmVXLQ@mail.gmail.com>
 <CABFgU_jJrRXDz2hgb95Znkr6Tict9t9CZBAffrE_zqChajqEvQ@mail.gmail.com>
Message-ID: <CAC9cSOA4DHswyW3ZAXBT4L_OFoGXDROLDVv-BHV7NTy0G2in0A@mail.gmail.com>

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>

From mdounin at mdounin.ru  Fri Feb 24 04:13:02 2023
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 24 Feb 2023 07:13:02 +0300
Subject: nginx serving corrupt images
In-Reply-To: <CABFgU_gjMvRet5kCVQTH--Ww2tmBS5oyjgzuayVj2V6=x2=6jA@mail.gmail.com>
References: <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <Y/gubnF79FGF7M4v@mdounin.ru>
 <CABFgU_gjMvRet5kCVQTH--Ww2tmBS5oyjgzuayVj2V6=x2=6jA@mail.gmail.com>
Message-ID: <Y/g5Tq0kcKOoeMbN@mdounin.ru>

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/

From venefax at gmail.com  Fri Feb 24 04:26:19 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 23:26:19 -0500
Subject: nginx serving corrupt images
In-Reply-To: <Y/g5Tq0kcKOoeMbN@mdounin.ru>
References: <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <Y/gubnF79FGF7M4v@mdounin.ru>
 <CABFgU_gjMvRet5kCVQTH--Ww2tmBS5oyjgzuayVj2V6=x2=6jA@mail.gmail.com>
 <Y/g5Tq0kcKOoeMbN@mdounin.ru>
Message-ID: <CAC9cSODu0NOMfrJCLoNzKXtuhOZTv5fDV-=gX9KbszWM_ai8tA@mail.gmail.com>

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>

From venefax at gmail.com  Fri Feb 24 04:46:47 2023
From: venefax at gmail.com (Saint Michael)
Date: Thu, 23 Feb 2023 23:46:47 -0500
Subject: nginx serving corrupt images
In-Reply-To: <CAC9cSODu0NOMfrJCLoNzKXtuhOZTv5fDV-=gX9KbszWM_ai8tA@mail.gmail.com>
References: <Y/awfEtssSm1tCJd@mdounin.ru>
 <CAC9cSOC1xoO72ueSCRt50Mj9RBKWmPoGv+1ECJX6U1WZ=hut+A@mail.gmail.com>
 <CABFgU_jNXy2Z-cCNxsURojjQnqYDzuzfyv0w4KJTs=Scsq=DDg@mail.gmail.com>
 <CABFgU_jTOVcyTi4PES61U7dMCR3wDcRRBE3vMxDUXnM72hYY+A@mail.gmail.com>
 <CAC9cSOCVqaeUOa-QFozKxVOnRcEVX5tHn0Dsxf-HRPmzzczA7w@mail.gmail.com>
 <CABFgU_gtGQrKsA+8vfR6zEVLS7BgLCbVJvih1TQkCys-WFjMhA@mail.gmail.com>
 <CABFgU_gVx9Zwwho6+BzVt7PCzKrp4JMcjq4yjkJ3UBduoTr1BQ@mail.gmail.com>
 <CABFgU_iNJy3peurccGQJwLufHbD_4Lv-9U0mPoK2vgB6irBpRA@mail.gmail.com>
 <Y/gubnF79FGF7M4v@mdounin.ru>
 <CABFgU_gjMvRet5kCVQTH--Ww2tmBS5oyjgzuayVj2V6=x2=6jA@mail.gmail.com>
 <Y/g5Tq0kcKOoeMbN@mdounin.ru>
 <CAC9cSODu0NOMfrJCLoNzKXtuhOZTv5fDV-=gX9KbszWM_ai8tA@mail.gmail.com>
Message-ID: <CAC9cSOANekBJUqnTyLEMwMMP51Z0DnGjD+V1XthEvbG2PGxz9g@mail.gmail.com>

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>

From venefax at gmail.com  Sat Feb 25 19:10:46 2023
From: venefax at gmail.com (Saint Michael)
Date: Sat, 25 Feb 2023 14:10:46 -0500
Subject: Connecting a reverse proxy to an http proxy service
Message-ID: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>

I have a problem reaching a news service that is protected by the evil CF.
I found out that there exist private HTTP proxy services, like webshare.io
the question is how I use them from nginx, and how do I add a pool of HTTP
proxies to the configuration?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230225/0f2cabec/attachment.htm>

From francis at daoine.org  Sat Feb 25 20:31:27 2023
From: francis at daoine.org (Francis Daly)
Date: Sat, 25 Feb 2023 20:31:27 +0000
Subject: Connecting a reverse proxy to an http proxy service
In-Reply-To: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>
References: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>
Message-ID: <20230225203127.GB6170@daoine.org>

On Sat, Feb 25, 2023 at 02:10:46PM -0500, Saint Michael wrote:

Hi there,

> that there exist private HTTP proxy services, like webshare.io
> the question is how I use them from nginx, and how do I add a pool of HTTP
> proxies to the configuration?

Stock nginx does not use the correct protocol to be able to talk to
upstream http proxy servers.

I'm not aware of a third-party module that lets it work.

Cheers,

	f
-- 
Francis Daly        francis at daoine.org

From teward at thomas-ward.net  Sat Feb 25 20:35:19 2023
From: teward at thomas-ward.net (Thomas Ward)
Date: Sat, 25 Feb 2023 20:35:19 +0000
Subject: Connecting a reverse proxy to an http proxy service
In-Reply-To: <20230225203127.GB6170@daoine.org>
References: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>
 <20230225203127.GB6170@daoine.org>
Message-ID: <MN0PR19MB5948F39A2C0F107D6DE20C6E9BA99@MN0PR19MB5948.namprd19.prod.outlook.com>

As Francis said, NGINX does not speak proxy protocols.

NGINX is the wrong tool for this job.



Sent from my Galaxy



-------- Original message --------
From: Francis Daly <francis at daoine.org>
Date: 2/25/23 15:31 (GMT-05:00)
To: nginx at nginx.org
Subject: Re: Connecting a reverse proxy to an http proxy service

On Sat, Feb 25, 2023 at 02:10:46PM -0500, Saint Michael wrote:

Hi there,

> that there exist private HTTP proxy services, like webshare.io
> the question is how I use them from nginx, and how do I add a pool of HTTP
> proxies to the configuration?

Stock nginx does not use the correct protocol to be able to talk to
upstream http proxy servers.

I'm not aware of a third-party module that lets it work.

Cheers,

        f
--
Francis Daly        francis at daoine.org
_______________________________________________
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/20230225/ff3bebb5/attachment.htm>

From venefax at gmail.com  Sat Feb 25 20:48:48 2023
From: venefax at gmail.com (Saint Michael)
Date: Sat, 25 Feb 2023 15:48:48 -0500
Subject: Connecting a reverse proxy to an http proxy service
In-Reply-To: <MN0PR19MB5948F39A2C0F107D6DE20C6E9BA99@MN0PR19MB5948.namprd19.prod.outlook.com>
References: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>
 <20230225203127.GB6170@daoine.org>
 <MN0PR19MB5948F39A2C0F107D6DE20C6E9BA99@MN0PR19MB5948.namprd19.prod.outlook.com>
Message-ID: <CAC9cSOCscsO_B3CnadBGL8NLUZzxfadMEpGnmAO7y-WFG1C-4Q@mail.gmail.com>

what would it be the right tool?



On Sat, Feb 25, 2023 at 3:35 PM Thomas Ward <teward at thomas-ward.net> wrote:

> As Francis said, NGINX does not speak proxy protocols.
>
> NGINX is the wrong tool for this job.
>
>
>
> Sent from my Galaxy
>
>
>
> -------- Original message --------
> From: Francis Daly <francis at daoine.org>
> Date: 2/25/23 15:31 (GMT-05:00)
> To: nginx at nginx.org
> Subject: Re: Connecting a reverse proxy to an http proxy service
>
> On Sat, Feb 25, 2023 at 02:10:46PM -0500, Saint Michael wrote:
>
> Hi there,
>
> > that there exist private HTTP proxy services, like webshare.io
> > the question is how I use them from nginx, and how do I add a pool of
> HTTP
> > proxies to the configuration?
>
> Stock nginx does not use the correct protocol to be able to talk to
> upstream http proxy servers.
>
> I'm not aware of a third-party module that lets it work.
>
> Cheers,
>
>         f
> --
> Francis Daly        francis at daoine.org
> _______________________________________________
> 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/20230225/cdf1f833/attachment.htm>

From pchychi at gmail.com  Sat Feb 25 20:52:05 2023
From: pchychi at gmail.com (Payam Chychi)
Date: Sat, 25 Feb 2023 12:52:05 -0800
Subject: Connecting a reverse proxy to an http proxy service
In-Reply-To: <CAC9cSOCscsO_B3CnadBGL8NLUZzxfadMEpGnmAO7y-WFG1C-4Q@mail.gmail.com>
References: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>
 <20230225203127.GB6170@daoine.org>
 <MN0PR19MB5948F39A2C0F107D6DE20C6E9BA99@MN0PR19MB5948.namprd19.prod.outlook.com>
 <CAC9cSOCscsO_B3CnadBGL8NLUZzxfadMEpGnmAO7y-WFG1C-4Q@mail.gmail.com>
Message-ID: <CAJMkcM3X5Rmc0r4XgvoAzebOpuG3z+WdaWCRSd5E0uGABKz=gQ@mail.gmail.com>

It may be worthwhile for you to take a step back and read about the
technologies and better understand the capabilities that these software
solutions provide.

It appears as if you are looking to this nginx list ad your own personal
self help repository.

Regards,
Payam



On Sat, Feb 25, 2023 at 12:49 PM Saint Michael <venefax at gmail.com> wrote:

> what would it be the right tool?
>
>
>
> On Sat, Feb 25, 2023 at 3:35 PM Thomas Ward <teward at thomas-ward.net>
> wrote:
>
>> As Francis said, NGINX does not speak proxy protocols.
>>
>> NGINX is the wrong tool for this job.
>>
>>
>>
>> Sent from my Galaxy
>>
>>
>>
>> -------- Original message --------
>> From: Francis Daly <francis at daoine.org>
>> Date: 2/25/23 15:31 (GMT-05:00)
>> To: nginx at nginx.org
>> Subject: Re: Connecting a reverse proxy to an http proxy service
>>
>> On Sat, Feb 25, 2023 at 02:10:46PM -0500, Saint Michael wrote:
>>
>> Hi there,
>>
>> > that there exist private HTTP proxy services, like webshare.io
>> > the question is how I use them from nginx, and how do I add a pool of
>> HTTP
>> > proxies to the configuration?
>>
>> Stock nginx does not use the correct protocol to be able to talk to
>> upstream http proxy servers.
>>
>> I'm not aware of a third-party module that lets it work.
>>
>> Cheers,
>>
>>         f
>> --
>> Francis Daly        francis at daoine.org
>> _______________________________________________
>> 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
>
-- 
Payam Tarverdyan Chychi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230225/d2b7bf7a/attachment-0001.htm>

From venefax at gmail.com  Sat Feb 25 21:15:29 2023
From: venefax at gmail.com (Saint Michael)
Date: Sat, 25 Feb 2023 16:15:29 -0500
Subject: Connecting a reverse proxy to an http proxy service
In-Reply-To: <CAJMkcM3X5Rmc0r4XgvoAzebOpuG3z+WdaWCRSd5E0uGABKz=gQ@mail.gmail.com>
References: <CAC9cSOBKJMLvk5ZvDy5et+232g-LEbLSYBjHtR2XmZerU+3Ktw@mail.gmail.com>
 <20230225203127.GB6170@daoine.org>
 <MN0PR19MB5948F39A2C0F107D6DE20C6E9BA99@MN0PR19MB5948.namprd19.prod.outlook.com>
 <CAC9cSOCscsO_B3CnadBGL8NLUZzxfadMEpGnmAO7y-WFG1C-4Q@mail.gmail.com>
 <CAJMkcM3X5Rmc0r4XgvoAzebOpuG3z+WdaWCRSd5E0uGABKz=gQ@mail.gmail.com>
Message-ID: <CAC9cSOAiGvbRB939J=vtMdwP-wKwxjcEtp8nJ+-Aopj4jrQFWg@mail.gmail.com>

I don't see what can be wrong with that. I also provide information for
free to people that need it.

On Sat, Feb 25, 2023 at 3:52 PM Payam Chychi <pchychi at gmail.com> wrote:

> It may be worthwhile for you to take a step back and read about the
> technologies and better understand the capabilities that these software
> solutions provide.
>
> It appears as if you are looking to this nginx list ad your own personal
> self help repository.
>
> Regards,
> Payam
>
>
>
> On Sat, Feb 25, 2023 at 12:49 PM Saint Michael <venefax at gmail.com> wrote:
>
>> what would it be the right tool?
>>
>>
>>
>> On Sat, Feb 25, 2023 at 3:35 PM Thomas Ward <teward at thomas-ward.net>
>> wrote:
>>
>>> As Francis said, NGINX does not speak proxy protocols.
>>>
>>> NGINX is the wrong tool for this job.
>>>
>>>
>>>
>>> Sent from my Galaxy
>>>
>>>
>>>
>>> -------- Original message --------
>>> From: Francis Daly <francis at daoine.org>
>>> Date: 2/25/23 15:31 (GMT-05:00)
>>> To: nginx at nginx.org
>>> Subject: Re: Connecting a reverse proxy to an http proxy service
>>>
>>> On Sat, Feb 25, 2023 at 02:10:46PM -0500, Saint Michael wrote:
>>>
>>> Hi there,
>>>
>>> > that there exist private HTTP proxy services, like webshare.io
>>> > the question is how I use them from nginx, and how do I add a pool of
>>> HTTP
>>> > proxies to the configuration?
>>>
>>> Stock nginx does not use the correct protocol to be able to talk to
>>> upstream http proxy servers.
>>>
>>> I'm not aware of a third-party module that lets it work.
>>>
>>> Cheers,
>>>
>>>         f
>>> --
>>> Francis Daly        francis at daoine.org
>>> _______________________________________________
>>> 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
>>
> --
> Payam Tarverdyan Chychi
> _______________________________________________
> 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/20230225/f54b966c/attachment.htm>

From venefax at gmail.com  Sun Feb 26 17:30:59 2023
From: venefax at gmail.com (Saint Michael)
Date: Sun, 26 Feb 2023 12:30:59 -0500
Subject: Reverse proxy
Message-ID: <CAC9cSODEo8LT7zjMd3PPEj0F3JnKxA4tVN7wRtozE46yS97FFg@mail.gmail.com>

In a location, ai need to use proxy_redirext to send the inbound cljent to
the second leg, another htpps.
But hiw do I tell nginx to follow an http_proxy? I can test from a terninal
session and the proxy workds fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230226/535df4e8/attachment.htm>