Subject: [Acme] nomenclature: “POST-as-GET”

From: Felipe Gasper <[email-masked]>
Date: Tue, 4 Sep 2018 13:43:16 -0400

FWIW, it seems to me like, if the HTTP verb being used is, in fact, “POST”, then a more appropriate term for the proposed fix for the identity correlation problem identified last week would be “GET-as-POST” rather than “POST-as-GET”.

“POST-as-GET” sounds to me like the actual HTTP verb is a GET, but we’re shoehorning what would normally be a POST over that request. The opposite, of course, is what is proposed: a POST with an uninteresting payload is being sent to simulate a GET but with the authentication of a POST. The pattern of a GET is being sent “as a POST”.

Alternatively, would it make sense to define a new HTTP verb, e.g., “FETCH”, for this?

-FG

---

From: Richard Barnes <[email-masked]>
Date: Tue, 4 Sep 2018 14:32:46 -0400

On Tue, Sep 4, 2018 at 1:44 PM Felipe Gasper <[email-masked]>
wrote:

> FWIW, it seems to me like, if the HTTP verb being used is, in fact,
> “POST”, then a more appropriate term for the proposed fix for the identity
> correlation problem identified last week would be “GET-as-POST” rather than
> “POST-as-GET”.
>
> “POST-as-GET” sounds to me like the actual HTTP verb is a GET, but we’re
> shoehorning what would normally be a POST over that request. The opposite,
> of course, is what is proposed: a POST with an uninteresting payload is
> being sent to simulate a GET but with the authentication of a POST. The
> pattern of a GET is being sent “as a POST”.
>

I would be fine either way.  It really just depends on which implicit verb
you read with the "as" -- "POST-acting-as-GET" or "GET-sent-as-POST".  I
would prefer not to actually include the verb, just because that gets wordy.

> Alternatively, would it make sense to define a new HTTP verb, e.g.,

I'm inclined not to do this.  We definitely shouldn't actually mint a new
HTTP method, since we're not changing the method.  As a corollary, we
shouldn't write it in all caps (so "Fetch" or "fEtcH" or something).  Also,
while "fetch" is the obvious verb, it collides with the HTML5 JS API of
that name, which supports all methods.

--Richard

>
> -FG
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Sep 2018 15:04:50 +1000

On Wed, Sep 5, 2018 at 4:33 AM Richard Barnes <[email-masked]> wrote:
> I'm inclined not to do this.  We definitely shouldn't actually mint a new HTTP method, since we're not changing the method.

One does not merely define a new verb.  The limited set of verbs in
HTTP is a feature, not a bug.  That means occasionally using POST in
ways that are suboptimal, but the alternative is struggling with an
unrecognized verb.

There is a proposal to add something with similar semantics to what
you describe, in SEARCH [1], but that has not been successful and it's
been a long time.  Don't kill ACME on this mountain.  Use POST and
learn to like it.

(Arguably, header fields are the way to deal with this class of
problem, but then we're into request signing territory and ACME
decided a long time ago not to tilt at that particular windmill.)

[1] https://tools.ietf.org/html/draft-snell-search-method-00 - which
died only partly because it conflicted with RFC 5323...