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?
Welcome to the web development community! This is a place to post, discuss, get help about, etc. anything related to web development
Web development is the process of creating websites or web applications
Some webdev blogs
Not sure what to post in here? Want some web development related things to read?
Heres a couple blogs that have web development related content
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.
If i was in control, rather quickly haha
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.