4 ms·

They could have used a GET method with a request body. Although it's debatable whether it's a better solution (semantically a request body should not influence

by molf 12y ago

They could have used a GET method with a request body. Although it's debatable whether it's a better solution (semantically a request body should not influence the result of an HTTP GET response), but saying that "GET requests don’t have a request body" is false.

tieTYT 12y ago
I had no idea that was an option so I researched it a bit and found this stackoverflow question: http://stackoverflow.com/questions/978061/http-get-with-request-body http://stackoverflow.com/questions/978061/http-get-with-requ... Note this part of the accepted answer: > So, yes, you can send a body with GET, and no, it is never useful to do so.
- Zikes 12y ago
  Specifically the intent was to say that it would be a violation of the HTTP/1.1 spec to change the response based on the contents of the message body, however if /delta used a hash of the message body contents in the URL then it should still be semantically correct.
  - jrochkind1 12y ago
    ooh, that's clever. but yeah, would be a pain for developers trying to actually work with the API, to have to create a hash just to make HTTP happy.
dragonwriter 12y ago
If the request body effects the behavior, they are breaking the semantics of GET and breaking anything (e.g., caching, including local) built around the defined semantics. There should be a GET-like method that takes a (significant) request body but is otherwise semantically like GET (e.g., safe) -- essentially, it would represent asking for a representation of the result of applying a pure function to the resource identified by the URI rather than asking for a representation of the resource itself. But no such function currently exists in HTTP/1.1 or any general purpose extension (there are highly-specific things like the SEARCH method, but that's not general purpose the way the base HTTP/1.1 methods and, say, PATCH are.)
- TheLoneWolfling 12y ago
  What about if the header included a hash of the content in the request body?
- treve 12y ago
  There's a REPORT method that can used with any content-type.
  - dragonwriter 12y ago
    If you mean the WebDAV one in RFC 3253, its spec (as is usual for WebDAV methods) has some WebDAV specific requirements in it that aren't really appropriate for general use; content-type isn't the only place where problems with generality can be found. Something like that completely decoupled from WebDAV is basically what I'd like to see.
ipsum2 12y ago
Yup, Elasticsearch ran into the same problem that Dropbox has, so they use request bodies to get around it. From: https://github.com/elasticsearch/elasticsearch-definitive-guide/commit/cff7de5722b127ce432a7b3017f103e4d7e9bf65 https://github.com/elasticsearch/elasticsearch-definitive-gu... : > A GET request with a body? The HTTP libraries of certain languages (notably Javascript) don’t allow GET requests to have a request body. In fact, some users are suprised that GET requests are ever allowed to have a body. > The truth is that RFC 7231 — the RFC which deals with HTTP semantics and content — does not define what should happen to a GET request with a body! As a result, some HTTP servers allow it, and some — especially caching proxies — don’t. > The authors of Elasticsearch prefer using GET for a search request because they feel that it describes the action — retrieving information — better than the POST verb. However, because GET with a request body is not universally supported, the search API also accepts POST requests:
- btilly 12y ago
  The significant difference here is that people using elastic search typically control the machines and network involved while Dropbox does not. Therefore it is OK for elastic search to say, "This is a reasonable way to work, and it is up to you to use compatible software etc." But a similar decision on Dropbox's part would mean that a random fraction of their customers would have a broken experience.
ashmud 12y ago
I ran across this when writing extension methods for HttpClient (.NET). HttpWebRequest did not like content-body being set for GET requests and threw this exception: System.Net.ProtocolViolationException: Cannot send a content-body with this verb-type.
- grrowl 12y ago
  I wonder how many lines of code contribute toward throwing that error? ;)

by molf 12y ago

tieTYT 12y ago

I had no idea that was an option so I researched it a bit and found this stackoverflow question: http://stackoverflow.com/questions/978061/http-get-with-request-body http://stackoverflow.com/questions/978061/http-get-with-requ... Note this part of the accepted answer: > So, yes, you can send a body with GET, and no, it is never useful to do so.

Zikes 12y ago
Specifically the intent was to say that it would be a violation of the HTTP/1.1 spec to change the response based on the contents of the message body, however if /delta used a hash of the message body contents in the URL then it should still be semantically correct.
- jrochkind1 12y ago
  ooh, that's clever. but yeah, would be a pain for developers trying to actually work with the API, to have to create a hash just to make HTTP happy.

dragonwriter 12y ago

If the request body effects the behavior, they are breaking the semantics of GET and breaking anything (e.g., caching, including local) built around the defined semantics. There should be a GET-like method that takes a (significant) request body but is otherwise semantically like GET (e.g., safe) -- essentially, it would represent asking for a representation of the result of applying a pure function to the resource identified by the URI rather than asking for a representation of the resource itself. But no such function currently exists in HTTP/1.1 or any general purpose extension (there are highly-specific things like the SEARCH method, but that's not general purpose the way the base HTTP/1.1 methods and, say, PATCH are.)

TheLoneWolfling 12y ago
What about if the header included a hash of the content in the request body?
treve 12y ago
There's a REPORT method that can used with any content-type.
- dragonwriter 12y ago
  If you mean the WebDAV one in RFC 3253, its spec (as is usual for WebDAV methods) has some WebDAV specific requirements in it that aren't really appropriate for general use; content-type isn't the only place where problems with generality can be found. Something like that completely decoupled from WebDAV is basically what I'd like to see.

ipsum2 12y ago

Yup, Elasticsearch ran into the same problem that Dropbox has, so they use request bodies to get around it. From: https://github.com/elasticsearch/elasticsearch-definitive-guide/commit/cff7de5722b127ce432a7b3017f103e4d7e9bf65 https://github.com/elasticsearch/elasticsearch-definitive-gu... : > A GET request with a body? The HTTP libraries of certain languages (notably Javascript) don’t allow GET requests to have a request body. In fact, some users are suprised that GET requests are ever allowed to have a body. > The truth is that RFC 7231 — the RFC which deals with HTTP semantics and content — does not define what should happen to a GET request with a body! As a result, some HTTP servers allow it, and some — especially caching proxies — don’t. > The authors of Elasticsearch prefer using GET for a search request because they feel that it describes the action — retrieving information — better than the POST verb. However, because GET with a request body is not universally supported, the search API also accepts POST requests:

btilly 12y ago
The significant difference here is that people using elastic search typically control the machines and network involved while Dropbox does not. Therefore it is OK for elastic search to say, "This is a reasonable way to work, and it is up to you to use compatible software etc." But a similar decision on Dropbox's part would mean that a random fraction of their customers would have a broken experience.

ashmud 12y ago

I ran across this when writing extension methods for HttpClient (.NET). HttpWebRequest did not like content-body being set for GET requests and threw this exception: System.Net.ProtocolViolationException: Cannot send a content-body with this verb-type.

grrowl 12y ago
I wonder how many lines of code contribute toward throwing that error? ;)