- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Makes a lot of sense - it’s a GET with the body from POST (I know, there’s more to it than that). Definitely cleaner than encoding a huge URL or query string.
However, we’re still implementing IPv6, so how long until we could actually use this?
I haven’t read through the whole spec to know what else is there, but the thing is, HTTP/1.1 always allowed GET to have a body. It was originally supposed to be ignored, but they gave up on that later on because it’s dumb.
However, we’re still implementing IPv6, so how long until we could actually use this?
We can already use custom verbs as we please: we only need to have clients and servers agree on a contract.
What we don’t have is the benefit of high-level “batteries included” web frameworks doing the work for us.
What about proxies and the like? It might be less relevant in a world where most communication happens under TLS.
Custom methods won’t have the benefit of being dealt with as if they shared specific semantics, such as being treated as safe methods or idempotent, but ultimately that’s just an expected trait that anyone can work with.
In the end, specifying a new standard HTTP method like QUERY extends some very specific assurances regarding semantics, such as whether frameworks should enforce CRSF tokens based on whether a QUERY has the semantics of a safe method or not.
If i was in control, rather quickly haha
