For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met...
The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time.
Also, the Datatracker URL is version-insensitive, so unlike the pure HTML format, it will not be stuck on draft-14 forever.
On my phone, your Datatracker link results in an unreadable mess of a page due to the hard-coded line breaks in the plaintext rendition of the RFC text (making it unreadable in portrait mode) and the huge sticky page nav (causing the content viewport to shrink vertically to almost zero in landscape mode). The HTML page behind OP's link reads just fine.
> The best way to view an RFC, IMHO, is to use the "htmlized" format
I don't see any choices of format such as HTML behind your link. There's a sticky nav, then a couple of pages of metadata, followed by a plaintext rendering of the RFC. What am I missing?
Also, the previous SEARCH method was proposed in Apr 2015 (!!), but nobody took it seriously, and it never gained traction back then. A lot of software was developed/updated during the last decade, and a lot of opportunities were missed. Even if the QUERY method is turned into a formal RFC right now, expect 10+ years for everyone to adopt it, without running into HTTP-405 or 501's.
See the history of the PATCH method, and of the whole WebDAV thing.
echo https://www.ietf.org/rfc/rfc$1.txt|yy025|nc -vv 6f6b 80|yy045|less
6f6b is TLS forward proxy
yy045 removes chunked encoding
less is more(1)
For drafts I use a metasearch script
+1 for non-paginated results
;;64) #``````````` datatracker
shift
x=$(echo "$x"|sed 's/ /+/g;s/++/+/g')
echo "https://datatracker.ietf.org/doc/search?name=$x&activedrafts=on&olddrafts=on"|yy025|(yy084 64 "$x";nc -vv 6f6b 80)
exit
It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.
I think this comment is terribly naive. Technically you can write your own service to support verbs like LOL or FUBAR, but in practice your service is not only expected to be broken when passing requests through other participants you do not control but also it requires far more development work to integrate with existing standards. Take for example CORS. If a HTTP method is not deemed safe then client requests need to go through the unsafe flow with preflight requests and the like. Forget support for caching too, and good luck having your requests pass through proxies.
So what exactly did you achieved by using non-standard verbs?
If you chose to go the ignorant backwards incompatible way, you are better off not using HTTP at all and just go with some random messaging/RPC protocol.
This allows the GET to bypass the 4k URL limit.
It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware).
I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.
The cases tend to look like this: - An endpoint was implemented as a GET endpoint, since it’s for getting data, with the search terms in the query parameters. The search term got too long, breaking a critical behavior in production environments. - An endpoint was implemented as a POST endpoint, despite it being an idempotent query for data, since the request body is too large to fit in query parameters. New employees repeatedly come in and are confused why it’s not a GET endpoint, or why it doesn’t modify anything.
I know this densest really work with ad-hock and cheap queries but it does for more expensive / report style ones.
With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.
One of the advantages of GET is the direct visibility, which makes modifications simple and easy for almost anyone (end users, testers, etc.).
The larger question I have is who will choose to adopt it sooner, with web servers, web application frameworks and web browsers in the mix.
If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks (if desired).
Completely worth bringing up and thinking about, but unless I'm missing something I don't think a QUERY verb will change all that much here?
The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.
Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.
You're bothering about non-issues. Bookmarks support GET requests, not any other verb. Like it has always been, if you need to support bookmarks then you implement bookmarkeable URLs to be used with GET requests.
Also, your far-fetched example failed to account for the fact that nowadays POST requests are used to query.
Looking at the logs I see that most of the long URI traffic is due to UTM and other tracking related codes, which are mainly a way to work around 3rd party cookie blocks.
I must be missing something, because it sounds like to goal is to have longer URI without the need for encoding URL parameters, but without using POST.
Suppose you have one filter but it has a few hundred twenty-character values.
Also another case is as a dev you are dealing with guids all day and it can be fast to swap guids around in the browser bar vs. ui steps.
That is perfectly fine. Sites that support path- and query-based filters are already designed specifically to have filters embedded in links, which are GET requests. The QUERY method is something more in line of a GraphQL style of query that isn't held back by the semantics of a POST request. GraphQL didn't invented this API style. If GraphQL-style APIs didn't affected how WebApps implemented links, QUERY methods won't.
Obviously query parameters are not going anywhere, but if this achieves enough adoption there is a future down the road where we can stop using POST for any query that wants a payload, without needing to change every single HTTP client in the world. (Many of them can already understand custom methods and treat them basically like posts.)
PathInfo is a thing you can absolutely use.
Presumably, because of that, many pages will continue to use query parameters for the foreseeable future. I think that's fine, but at least for APIs, the QUERY method could eventually be a very nice thing to have.
What you are actually doing when making a specific kind of request is assuming the actual properties match the documented properties and acting accordingly.
A QUERY seems to be no more than a POST that documents it is idempotent. Furthermore, you should only QUERY a resource that has advertised it is idempotent via the “Accept-Query” header. You might as well name that the “Idempotent-Post” header and then you just issue a POST; exactly the same information and properties were expressed and you do not need a new request type to support it.
Adding a new http method is the only way to support something like this safely. If something in between doesn't know what to do with QUERY it can just respond with a 501.
Fun fact - GET and HEAD are the only required methods one needs to implement to be an http server. It is a pretty low bar :)
The RFC is pretty clear that no participant in a HTTP request is expected to even allow a GET request through. RFC 9110 even states quite clearly that it's even a potential request smuggling attack. Some major cloud providers provide API Gateway implementations that outright strip request bodies from GET requests.
I think you are missing the whole point of proposing a new HTTP verb. Changing the semantics of a GET request is not an option because of both the security risks it presents and the fact that the infrastructure of the whole internet either is designed to reject these requests or outright breaks. See how GET requests are cached and how cache implementations don't discriminate GET requests based on it's request body.
https://lists.w3.org/Archives/Public/ietf-http-wg/
There's also some tracking on GitHub.
https://github.com/httpwg/http-extensions/issues?q=label%3Aq...
I love the idea of a separate verb. It always felt like get is just not quite enough.
POST to /reports with the query parameters in the body. Respond with bookmarkable, cacheable /reports/id and GET /reports/id
And that’s only necessary for huge, complex queries. If filtering some resources doesn’t fit into the URL you might want to rethink what you’re doing.
Not as good as a standardized idempotent Method, but good enough for the time being till they finally approve this as RFC
I encountered a codebase with only POST for all operations, given my lack of knowledge in this area, I am not sure why one would choose POST only over the standard set of GET, PUT, POST, DELETE, etc.
POST: I want to change stuff.
I don't know how this style cannot match cleanly any architecture.
It's not supposed to be a map to CRUD, it's a bunch of building blocks for manipulating state over a network.
That's also why I only use a couple of status codes: Ok, Created, NoContent, BadRequest, Forbidden, Unauthorized an InternalServerError (the latter two generated automatically by the framework).
GET, PUT, DELTE, etc. seem to be tailored towards entities, but as soon as the endpoint is not an "entity", the semantics get vague and break down.
... and they don't use GET everywhere because one time Google scraped that endpoint and dropped the production database.
Obviously doesn’t work with all systems, but QUERY works with even fewer.
Waste of time.
FYI: QUERY is for GET requests where the query string make the URL too long. It does this by sending a body like POST.
In the past, POST meant you were sending a body, and GET meant you received a body. And the people got religious about a pseudoacronym called REST.