Hello
May I ask how to monitor nginx ssl-session-cache status
For instance:
How much ssl-session-cache has been used, how much left
How many Session-ID are saving
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hey Chinmay!
Use tcpdump or tshark.
Patrick
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hello,
Is there a way to log individual websocket messages going through a nginx
server setup to proxy websocket as explained here
https://nginx.org/en/docs/http/websocket.html ?
-Chinmay
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/m
BTW, if I set error_log to "warn", I do see:
2020/12/01 00:32:46 [warn] 7356#7356: *1 using uninitialized "test_var"
variable while logging request, client: 127.0.0.1, server: _, request: "GET
/ HTTP/1.1", host: "localhost"
The confusion was whether those uninitialized variables should be logged
Thanks Maxim,
If I understand correctly, the uninitialized custom variable is the same as
a variable initialized as "". That's why we don't see "-", but only see "".
Only internal variables will have the special "-" treatment.
Frank
On Mon, Nov 30, 2020 at 4:27 PM Maxim Dounin wrote:
> Hello!
Hello!
On Mon, Nov 30, 2020 at 03:26:59PM -0800, Frank Liu wrote:
> ok, for testing, I removed the variable from the map, and add one line in a
> 2-way SSL server config, to create a fresh new variable:
>
> set $test_var "test";
>
> For a request without client cert (400), I see neither "test",
ok, for testing, I removed the variable from the map, and add one line in a
2-way SSL server config, to create a fresh new variable:
set $test_var "test";
For a request without client cert (400), I see neither "test", nor "-" in
the access log for $test_var. I only see blank, as if the $test_var
Hello!
On Mon, Nov 30, 2020 at 02:04:35PM -0800, Frank Liu wrote:
> I may have mixed this with special upstream variables, eg:
> $upstream_http_something. When upstream response header doesn't existing,
> the variable was logged - in the nginx access logs.
When a variable value is not found, it'
Hello!
On Mon, Nov 30, 2020 at 06:41:18PM +0100, Andreas Bartelt wrote:
> On 11/30/20 4:07 PM, Maxim Dounin wrote:
> > Hello!
> >
> > On Sun, Nov 29, 2020 at 04:01:07PM +0100, ng...@bartelt.name wrote:
> >
> >> I've noticed that nginx 1.18.0 always enables TLS 1.3 even if not
> >> configured to
I may have mixed this with special upstream variables, eg:
$upstream_http_something. When upstream response header doesn't existing,
the variable was logged - in the nginx access logs.
On Mon, Nov 30, 2020 at 5:28 AM Maxim Dounin wrote:
> Hello!
>
> On Sun, Nov 29, 2020 at 05:35:19AM -0800, Fran
On 11/30/20 4:07 PM, Maxim Dounin wrote:
Hello!
On Sun, Nov 29, 2020 at 04:01:07PM +0100, ng...@bartelt.name wrote:
I've noticed that nginx 1.18.0 always enables TLS 1.3 even if not
configured to do so. I've observed this behavior on OpenBSD with (nginx
1.18.0 linked against LibreSSL 3.3.0) an
Hello!
On Sun, Nov 29, 2020 at 04:01:07PM +0100, ng...@bartelt.name wrote:
> I've noticed that nginx 1.18.0 always enables TLS 1.3 even if not
> configured to do so. I've observed this behavior on OpenBSD with (nginx
> 1.18.0 linked against LibreSSL 3.3.0) and on Ubuntu 20.04 (nginx 1.18.0
> l
Hello!
On Sun, Nov 29, 2020 at 05:35:19AM -0800, Frank Liu wrote:
> If I create a variable, default to blank:
>
>map upstream_env $upstream_env {
>default "";
>}
>
> and log it in access log (log_format has $upstream_env). I see a "-" in the
> log file, which is as expected, but
Thanks for your reply.
I've recompiled nginx on OpenBSD in order to get rid of the LibreSSL
version mismatch which is gone now:
# nginx -V
nginx version: nginx/1.18.0
built with LibreSSL 3.3.0
Unfortunately, this didn't solve the problem, i.e., TLS 1.3 is still
enabled on my OpenBSD/nginx set
14 matches
Mail list logo
