"https://www.thomas-walker-lynch.com"; is picked up by a server block with a
different virtual host name. A bit of a head scratcher so perhaps the
experts here can tell me what rookie mistake I have made? Detailed
information and .txt file versions of the conf files at this link.
thomaswlynch.co
Hey, did you manage to solve it somehow?
Today I had the same issue:
First, an error about "ignore long locked inactive cache":
2022/01/06 16:25:57 [alert] 1851#1851: ignore long locked inactive cache
entry 296f4c8a7a86be9ab8b0b1f7a36a24c9, count:1
2022/01/06 16:25:57 [alert] 1851#1851: ignore lon
Thanks Francis, Maxim,
I think that the docs are fine.
Coming from an OS/network world and not steeped in HTTP, I had mentally
reversed the concepts of location and root.
All is (almost) clear now.
Bob
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,293215,293273#msg-293273
__
Hello!
On Wed, Jan 05, 2022 at 03:33:29PM +, Marti, Ueli (Marin) wrote:
> Ok, good point thanks.
> However, it seems nginx accepts only one ssl_ocsp_responder
> instance. Or is there a syntax to specify multiple instances ?
> So this would need to be solved on the responder side which
> wou
On Thu, Jan 06, 2022 at 08:37:46AM -0500, David27 wrote:
Hi there,
It's better for future readers if you include the full details in the
email; but in this case it seems straightforward based on the url content
I see.
> "https://www.thomas-walker-lynch.com"; is picked up by a server block with a
On Wed, Jan 05, 2022 at 10:03:52PM -0500, chakras wrote:
Hi there,
> I am using nginx on a VPS to proxy requests to a GCP server. When working
> with IPv4, everything works as desired. However, if we enable IPv6 on client
> machine, we see that the first call (/auth) fails with 401, and all
> sub
Hello Francis,
Thanks for your response. I have verified from Network logs on the browser
that POST request is sending the username and password in both cases. So, I
wasn't sure if additional headers need to be sent for switching to happen
seamlessly. The issue is after that first failure there is
Hi,
ok that makes sense.
Thank you for the feedback.
-Original Message-
From: nginx On Behalf Of Maxim Dounin
Sent: Thursday, January 6, 2022 9:36 PM
To: nginx@nginx.org
Subject: Re: OCSP, client certificate verification with chained CA
CAUTION: This email originated outside the company.