Some New HTTP Verbs

Re:Some New HTTP Verbs by svieira on Tuesday September 13, 2022 @09:19AM (#32823888)

It's not about the "end user" developer of the server, it's about the middleware and the clients. A browser (for example) will happily retry a GET request that times out, but will not automatically retry a POST request that does the same. Will that break a badly behaved web API? Yes. But that's like saying that "calling conventions are a useless spandrel because the consuming code can ignore the convention and just read from arbitrary memory".

[ Parent | on HN ]

Re:Some New HTTP Verbs by Sohcahtoa82 on Tuesday September 13, 2022 @11:30AM (#32825599)

I agree.

I can understand the annoyance for there being so many verbs, but at the very least, there must be two: One that is guaranteed to be idempotent, and one that isn't.

Someone I know was trying to make a message board that was compatible with every browser. EVERY browser. Including Mosaic and Netscape 1.0. Which meant that everything was done using GET requests, including posting messages.

He changed his tune when some spidering engine found his site and issued tons of GET requests that ended up flooding the board with comments and posts that looked like web search queries.

[ Parent | on HN ]

Re:Some New HTTP Verbs by P5fRxh5kUvp2th on Tuesday September 13, 2022 @12:20PM (#32826368)

I find that hilarious because that used to be such a well understood phenomenon that I can't believe no one told him about it.

OTOH, sometimes the best teacher is experience.

[ Parent | on HN ]

Re:Some New HTTP Verbs by samatman on Tuesday September 13, 2022 @11:07AM (#32825271)

That's actually a good example, because if the standard specified that POST must be idempotent, and that a POST without a uuid is invalid, we might have something here.

Instead there's a workaround for a serious problem, and any client (browser being by no means the only client) which doesn't respect the convention can emit identical POSTs, with no way of knowing if that was intended.

[ Parent | on HN ]

Re:Some New HTTP Verbs by svieira on Tuesday September 13, 2022 @11:13AM (#32825369)

The standard says "POST means NOT-IDEMPOTENT" and "clients MUST not re-issue a non-idempotent requests" and the client behavior naturally falls out of those two constraints.

[ Parent | on HN ]

Re:Some New HTTP Verbs by samatman on Tuesday September 13, 2022 @11:15AM (#32825397)

The standard being completely backward and impossible to enforce is a problem!

[ Parent | on HN ]

Re:Some New HTTP Verbs by P5fRxh5kUvp2th on Tuesday September 13, 2022 @12:21PM (#32826383)

standards are agreements, they've never been there with the expectation of enforcement.

[ Parent | on HN ]

Re:Some New HTTP Verbs by samatman on Tuesday September 13, 2022 @12:26PM (#32826457)

Unenforceable and unenforced are very different things.

[ Parent | on HN ]

Re:Some New HTTP Verbs by P5fRxh5kUvp2th on Tuesday September 13, 2022 @12:33PM (#32826559)

Unless you've got state actors behind it, it's unenforceable, full stop.

We saw this when MS would regularly ignore HTML standards.

[ Parent | on HN ]

Re:Some New HTTP Verbs by Ajedi32 on Tuesday September 13, 2022 @11:23AM (#32825500)

POST is intentionally not idempotent. If you want impotence, that's what PUT and DELETE are for. Sadly, browser support for those two methods is somewhat lacking. You can't specify that a form send a PUT request, for example, only GET or POST.

[ Parent | on HN ]

Re:Some New HTTP Verbs by Ferret7446 on Tuesday September 13, 2022 @05:57PM (#32830690)

You're looking for PUT.

[ Parent | on HN ]