From: Daniel Berteaud <daniel@firewall-services.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH proxmox-acme 1/1] Close the acme standalone connection after sending a response
Date: Thu, 1 Oct 2020 12:55:06 +0200 (CEST) [thread overview]
Message-ID: <1408702569.181241.1601549706910.JavaMail.zimbra@fws.fr> (raw)
In-Reply-To: <1601543152.9js94vfimk.astroid@nora.none>
----- Le 1 Oct 20, à 11:15, Fabian Grünbichler f.gruenbichler@proxmox.com a écrit :
> On September 30, 2020 4:09 pm, Daniel Berteaud wrote:
>> Without this, the first req get a response, but not the next ones as the
>> listeners stays busy
>> Fixes #3048
>>
>> Signed-off-by: Daniel Berteaud <daniel@firewall-services.com>
>> ---
>> src/PVE/ACME/StandAlone.pm | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/PVE/ACME/StandAlone.pm b/src/PVE/ACME/StandAlone.pm
>> index 0e2ece6..552c35c 100644
>> --- a/src/PVE/ACME/StandAlone.pm
>> +++ b/src/PVE/ACME/StandAlone.pm
>> @@ -55,8 +55,8 @@ sub setup {
>> } else {
>> $c->send_error(404, 'Not found.')
>> }
>> + $c->close();
>
> I think this is not right - we only end up looping/blocking on
> get_request if the client requested keep alive, in which case the server
> should obviously not close the connection..
>
> I guess we have to fork (up to some limit) on accept()? it's obviously
> not ideal that anybody can race with the LE validation attempts and
> block the single request handler ;)
Indeed, having a few more handlers could limit the risk of this happening.
>
> maybe you can change something in your apache config to close the
> connection (or rather, to propagate the connection closing from the
> actual client)? it looks like this can only affect you if
> - your apache proxy keeps the connection open
> - your apache proxy does not re-use the open connection
You're right, the issue was on my rev proxy, which didn't re-used keep-alived connexions as it should (it was an old httpd 2.2.3 on a CentOS 5 box, on which I had no control).
Switching my setup so it now runs behind a nginx proxypass works normaly without any modification
Sorry for not having looked at this more closely before posting ;-)
Cheers,
Daniel
--
[ https://www.firewall-services.com/ ]
Daniel Berteaud
FIREWALL-SERVICES SAS, La sécurité des réseaux
Société de Services en Logiciels Libres
Tél : +33.5 56 64 15 32
Matrix: @dani:fws.fr
[ https://www.firewall-services.com/ | https://www.firewall-services.com ]
next prev parent reply other threads:[~2020-10-01 10:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 14:09 [pve-devel] [PATCH proxmox-acme 0/1] " Daniel Berteaud
2020-09-30 14:09 ` [pve-devel] [PATCH proxmox-acme 1/1] " Daniel Berteaud
2020-10-01 9:15 ` Fabian Grünbichler
2020-10-01 10:55 ` Daniel Berteaud [this message]
2020-10-01 11:55 ` Fabian Grünbichler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1408702569.181241.1601549706910.JavaMail.zimbra@fws.fr \
--to=daniel@firewall-services.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.