[pbs-devel] [PATCH proxmox{, -backup} 0/2] fix #6939: acme: support servers returning 204 for nonce requests

[Thomas Lamprecht]

Thanks for the patch and actually also checking if PVE is affected, and why
it isn't.

Am 28.10.25 um 20:34 schrieb Samuel Rufinatscha:
> This is also stricter than the PVE Perl ACME client, which tolerates any
> 2xx success codes [3]. The author mentions, the issue did not appear
> with PVE9 [1].
> 
> ## Ideas to solve the problem
> 
> To support ACME providers which return 204 No Content, the underlying
> ACME clients need to tolerate both 200 OK and 204 No Content as valid
> responses for the nonce HEAD request, as long as the Replay-Nonce is
> provided.
> 
> I considered following solutions:
> 
> 1. Change the `expected` field of the `AcmeRequest` type from `u16` to
>    `Vec<u16>`, to support multiple success codes
> 
> 2. Keep `expected: u16` and add a second field e.g. `expected_other:
>    Vec<u16>` for "also allowed" codes.
> 
> 3. Support any 2xx success codes, and remove the `expected` check
> 
> I thought (1) might be reasonable, because:
> 
> * It stays explicit and makes it clear which statuses are considered
>   success.
> * We don’t create two parallel concepts ("expected" vs
>   "expected_other") which introduces additional complexity
> * Can be extend later if we meet yet another harmless but not 200
>   variant.
> * We don’t allow arbitrary 2xx.
> 
> What do you think? Do you maybe have any other solution in mind that
> would fit better?

There probably isn't answer that strictly right in all cases, but in
general it's good to have similar behavior across implementations,
especially given that we do not know of any report where the PVE behavior
of accepting all 2xx response codes caused any problems, from that 3.
would be best, or does the RFC forbid the server to accept other status
codes?

That said, in practice only 201 (Created) might make sense for ACME in
addition to the referenced 200 (OK) and 204 (No Content), and following
the RFC is fine, so 1. is IMO also a good solution here.
Please note the difference to PVE in the commit message, there you write
that behavior is now aligned with PVE, but it's rather "closer aligned"
to, not fully.