POST-as-GET and empty payload instead of {}

Client dev
1

Hello,
I’ve just implemented POST-as-GET update on v2 in our ACME client. And one question appeared:

Why is there empty payload “” instead of empty JSON payload “{}” (after Base64Url “e30”) like in confirm challenge?.

This brings ugly irregularity to the codebase. Purpose of POST-as-GET concept seems just to authenticate and add nothing else. Just as confirm challenge with {} content does. Sending {} also provides base for future updates or optional extensions of the ACME protocol itself.

This might be more ACME-spec question, but I’m not sure where else discuss this.

1 Like
2

Hi @PavlinII

Great! :tada:

Its a signal to differentiate between an idempotent POST-as-GET to fetch a challenge's details vs a POST to initiate the challenge. If the {} body were used for both it wouldn't be possible for a server to easily distinguish between a fetch and a challenge initiation.

Believe me when I say that I agree that POST-as-GET is generally ugly and irregular :laughing: Part of the reason is that this was a late addition to the specification that was raised during the IESG review.

It is indeed an ACME spec question. There was a fair amount of debate about the mechanism used to differentiate POST-as-GET from a challenge update in the history of both the acme Github repo and the mailing list. There were a few alternatives posed but this is where consensus landed.

It's too late to change this for the base ACME protocol draft (it's perhaps only days away from being an RFC!) but the historic discussion might be interesting to you if you're interested in proposing independent updates to the specification down the road.

6 Likes
3

“fetch details” vs. “initiate the challenge” clarifies my doubt.

I’ll put some ugly, irregular and mean comment into our code :slight_smile:

Thank you.

3 Likes
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.