>GET requests don’t have a request body, so all parameters must appear in the URL or in a header.
GETs can have bodies--- its just that some people who write software forget this.
A simple solution is to put a hash or maybe even just a body content length in the query string or a header so the server can make sure the body made it to it. If the the body doesn't make it, then it can inform the client retry with another less ideal HTTP method.
There's another article currently on the first page of HN discussing this issue. That post has a pointer to this [1] stackoverflow with the following quote from Roy Fielding:
Yes. In other words, any HTTP request message is allowed to contain a message body,
and thus must parse messages with that in mind. Server semantics for GET, however,
are restricted such that a body, if any, has no semantic meaning to the request.
The requirements on parsing are separate from the requirements on method
semantics.
So, yes, you can send a body with GET, and no, it is never useful to do so.
This is part of the layered design of HTTP/1.1 that will become clear again once
the spec is partitioned (work in progress).
....Roy
Does that actually work in practice? Will the body make it through various opinionated routers, WAFs, etc? (I have no idea, but if not, it doesn't matter.)
It often does, and if not, the above approach is to inform your client of the failure so it can switch to using POST or whatever else is best.
Edit: As I mentioned on another follow up, you may need to vary on your checksum header to play nice with proxy caches, etc. Or mark your responses as uncachable.
Given the apparent desire to have GET-like requests with bodies that have meaning to the server, would there be any downside to introducing a new method for that purpose, lets say... QUERY?
So for example: QUERY example.com/api/thing ('{"thing_id": 00335}'::json)
GETs can have bodies--- its just that some people who write software forget this.
A simple solution is to put a hash or maybe even just a body content length in the query string or a header so the server can make sure the body made it to it. If the the body doesn't make it, then it can inform the client retry with another less ideal HTTP method.