3 ms·

>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 s

>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.

aros 12y ago
By "some people", I assume that you mean many of the most popular http-based servers and frameworks.
craigching 12y ago
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 [1] -- http://stackoverflow.com/questions/978061/http-get-with-request-body http://stackoverflow.com/questions/978061/http-get-with-requ...
- voidlogic 12y ago
  I should point out if you use my above approach and vary on the checksum/hash header, you don't even break the semantics here either...
serve_yay 12y ago
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.)
- voidlogic 12y ago
  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.
s_kilk 12y ago
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)

aros 12y ago

By "some people", I assume that you mean many of the most popular http-based servers and frameworks.

craigching 12y ago

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 [1] -- http://stackoverflow.com/questions/978061/http-get-with-request-body http://stackoverflow.com/questions/978061/http-get-with-requ...

voidlogic 12y ago
I should point out if you use my above approach and vary on the checksum/hash header, you don't even break the semantics here either...

serve_yay 12y ago

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.)

voidlogic 12y ago
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.

s_kilk 12y ago

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)