RFC 10008: The HTTP QUERY Method | RFC Editor

submitted by
edited

https://www.rfc-editor.org/info/rfc10008/

Latest proposed method since PATCH from 2010, and PRI from 2015?

12
19
2

Log in to comment

Hot Top New Old

I would love this. Had an excellent search system that required no server state… But i could only use POST for large requests. Which was a pain.

 reply
5

I’m not very familiar with the format of RFCs. Is this approved and is going to ship to clients and servers, or still a draft?

 reply
4

I missed it at first myself, but it’s right near the top under the title and author list: proposed standard.

 reply
6

Aah, thanks. I really like the idea of this QUERY method.

 reply
3

Glad to see nore progress on this, but damn, it sure is slow goings. Not to mention that there’s been an obvious need for this for at least a decade.

 reply
3

Comments in Programming@programming.dev

edited

This is pretty good, though I expect even if it’s accepted it’s going to be a long journey before you can reliably use it

If we’re adding stuff to http, it would be nice for some additional status codes, things have moved on a bit since the early days

 reply
7

There should be a 400 that just says “fuck you and your AI”

 reply
15

I believe you can use 422: Unprocessable Content for this.

The request was well-formed (i.e., syntactically correct) but could not be processed.

“I know what you said, but I’m not answering you.”

 reply
11

That’s what 418 is for imo

 reply
5

I like it. Let’s do it.

 reply
5

While I like the goal of this, why not errata the existing spec to allow GET requests to have bodies? Would that be too much of a breaking change?

 reply
2

Adding stuff is easier than patching existing implementations is probably the reason why. Because up until this point, the webserver can just ignore the GET body request but if the client starts sending with body then who knows what bug might surface that turns into security vulnerability.

 reply
4
Insert image