5 ms·

The new QUERY method strikes me as a really promising addition. Not being able to send a body with a GET-type request is a gnawing issue I have with HTTP

0xb0565e487 4y ago
Just send a POST request lol
- HideousKojima 4y ago
  But you're only "supposed" to use POST with requests that add/modify data, or something silly like that. In practice, QUERY is most useful for where you want a bunch of different verbs for the same endpoint and need a body.
- spiffytech 4y ago
  QUERY is cacheable.
  - est 4y ago
    ... in theory only. Not that many http cache programs support QUERY. And many HTTP middle-boxes bans non GET/POST verbs.
    - counttheforks 4y ago
      For now. Change has to come from somewhere.
  - cogman10 4y ago
    And retry-able.
- duxup 4y ago
  In practice I think that’s exactly what many people do.
- Existenceblinks 4y ago
  GraphQL is doomed?
  - RedShift1 4y ago
    No, this would actually be very useful for GraphQL API's.
- NickLamp 4y ago
  I do... but there are good reasons to not want to. If you read the linked spec you can learn for yourself https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...
Waterluvian 4y ago
Is it that you can but you’re just told not to, even if both client and server agree on the semantics?
bruce511 4y ago
Interestingly though GET with data exists in the wild, and has for many years. I manage a http library class, and a customer encountered an API that required a GET but with data. (think query parameters passed as XML). I implemented that for the customer, and then implemented the reverse in the server class. I'm not going to say its used a lot, but it makes semantic sense. Incidentally it also becomes true for DELETE which is another request typically without a body. This is the first I've heard of QUERY though, so look forward to reading up on that.
- sakisv 4y ago
  Just a heads-up that cloudfront will return a 403 when it receives a GET with body. It's documented and all but I still find it a peculiar choice. A 400 would have been better and less of a red herring.
  - jshier 4y ago
    It also produces an error on all Apple platforms, as it's banned by URLSession.
  - deleted 4y ago
    [deleted]
asdfghjhgfderty 4y ago
nothing on the spec prevents arbitrary data on body of a GET. but clients and proxies are implemented by lazy people who make excuses they are preserving some legacy security feature or something and continue to ignore the spec.
- insanitybit 4y ago
  The spec is actually pretty clear on this - do not specify a body on a GET request. > A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. Previously it was "SHOULD ignore the payload". It's nothing to do with laziness or security - people are writing spec conforming software. And indeed every library I've used allows interacting with a body, even on a GET.
  - simplotek 4y ago
    > The spec is actually pretty clear on this - do not specify a body on a GET request. That's not what your quote says. Not having a defined semantics does not mean if is not supported. Just because some implementations fail to support GET with a request body that it does not mean all implementations should interpret it as a malformed request. I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP.
    - masklinn 4y ago
      > That's not what your quote says. Yes it does. "No defined semantics" = "out of spec". > I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP. You're out of the HTTP spec entirely.
      - mekster 4y ago
        How are you interpreting that English? Not defined means, it could be anything. If accepting body in GET is out of spec, then spec is supposed to say, GET cannot send body.
a_c 4y ago
Elastic search (used to?) use HTTP body as parameters for a GET request. IIRC the HTTP specification doesn't (again, used to?) mandate GET request to have no HTTP body Edit: Example of Elastic search API with GET body, now deprecated https://www.elastic.co/guide/en/elasticsearch/reference/7.7/search-request-body.html https://www.elastic.co/guide/en/elasticsearch/reference/7.7/... Edit 2: https://stackoverflow.com/questions/978061/http-get-with-request-body https://stackoverflow.com/questions/978061/http-get-with-req... The now obsolete specification https://www.rfc-editor.org/rfc/rfc2616 https://www.rfc-editor.org/rfc/rfc2616 , obsoleted by https://www.rfc-editor.org/rfc/rfc9110 https://www.rfc-editor.org/rfc/rfc9110
- jillesvangurp 4y ago
  It still does. I don't think it violates the HTTP 1.1 specification but more that it is unspecified. It's just that a lot of http clients simply don't support doing HTTP GET with a body under the assumption that it is redundant / not needed / forbidden. Of course elasticsearch allows POST as an alternative. People used to obsess a lot more about those HTTP verbs and their meaning a lot more than today. At least I don't seem to get dragged into debates on the virtues of PUT vs. POST, or using PATCH for a simple update API. If you use graphql, everything is a POST anyway. Much like SOAP back in the day. It's all just different ways to call stuff on servers. Remote procedure calls have a long history that predates all of the web.
  - pixl97 4y ago
    I feel not obsessing about the meanings of HTTP verbs can, has, and will lead to security incidents and interoperability issues between middleware. Specifications where everyone gets to pick and choose different behaviors is a nightmare.
    - int_19h 4y ago
      The obsession with fine-grained distinctions may be gone, but GET/POST is still relevant when talking about caching etc.
  - 4y ago

0xb0565e487 4y ago

Just send a POST request lol

HideousKojima 4y ago
But you're only "supposed" to use POST with requests that add/modify data, or something silly like that. In practice, QUERY is most useful for where you want a bunch of different verbs for the same endpoint and need a body.
spiffytech 4y ago
QUERY is cacheable.
- est 4y ago
  ... in theory only. Not that many http cache programs support QUERY. And many HTTP middle-boxes bans non GET/POST verbs.
  - counttheforks 4y ago
    For now. Change has to come from somewhere.
- cogman10 4y ago
  And retry-able.
duxup 4y ago
In practice I think that’s exactly what many people do.
Existenceblinks 4y ago
GraphQL is doomed?
- RedShift1 4y ago
  No, this would actually be very useful for GraphQL API's.
NickLamp 4y ago
I do... but there are good reasons to not want to. If you read the linked spec you can learn for yourself https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

Waterluvian 4y ago

Is it that you can but you’re just told not to, even if both client and server agree on the semantics?

bruce511 4y ago

Interestingly though GET with data exists in the wild, and has for many years. I manage a http library class, and a customer encountered an API that required a GET but with data. (think query parameters passed as XML). I implemented that for the customer, and then implemented the reverse in the server class. I'm not going to say its used a lot, but it makes semantic sense. Incidentally it also becomes true for DELETE which is another request typically without a body. This is the first I've heard of QUERY though, so look forward to reading up on that.

sakisv 4y ago
Just a heads-up that cloudfront will return a 403 when it receives a GET with body. It's documented and all but I still find it a peculiar choice. A 400 would have been better and less of a red herring.
- jshier 4y ago
  It also produces an error on all Apple platforms, as it's banned by URLSession.
- deleted 4y ago
  [deleted]

asdfghjhgfderty 4y ago

nothing on the spec prevents arbitrary data on body of a GET. but clients and proxies are implemented by lazy people who make excuses they are preserving some legacy security feature or something and continue to ignore the spec.

insanitybit 4y ago
The spec is actually pretty clear on this - do not specify a body on a GET request. > A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request. Previously it was "SHOULD ignore the payload". It's nothing to do with laziness or security - people are writing spec conforming software. And indeed every library I've used allows interacting with a body, even on a GET.
- simplotek 4y ago
  > The spec is actually pretty clear on this - do not specify a body on a GET request. That's not what your quote says. Not having a defined semantics does not mean if is not supported. Just because some implementations fail to support GET with a request body that it does not mean all implementations should interpret it as a malformed request. I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP.
  - masklinn 4y ago
    > That's not what your quote says. Yes it does. "No defined semantics" = "out of spec". > I can roll out a service with endpoints that require GET with request bodies and it would still be valid HTTP. You're out of the HTTP spec entirely.
    - mekster 4y ago
      How are you interpreting that English? Not defined means, it could be anything. If accepting body in GET is out of spec, then spec is supposed to say, GET cannot send body.

a_c 4y ago

Elastic search (used to?) use HTTP body as parameters for a GET request. IIRC the HTTP specification doesn't (again, used to?) mandate GET request to have no HTTP body Edit: Example of Elastic search API with GET body, now deprecated https://www.elastic.co/guide/en/elasticsearch/reference/7.7/search-request-body.html https://www.elastic.co/guide/en/elasticsearch/reference/7.7/... Edit 2: https://stackoverflow.com/questions/978061/http-get-with-request-body https://stackoverflow.com/questions/978061/http-get-with-req... The now obsolete specification https://www.rfc-editor.org/rfc/rfc2616 https://www.rfc-editor.org/rfc/rfc2616 , obsoleted by https://www.rfc-editor.org/rfc/rfc9110 https://www.rfc-editor.org/rfc/rfc9110

jillesvangurp 4y ago
It still does. I don't think it violates the HTTP 1.1 specification but more that it is unspecified. It's just that a lot of http clients simply don't support doing HTTP GET with a body under the assumption that it is redundant / not needed / forbidden. Of course elasticsearch allows POST as an alternative. People used to obsess a lot more about those HTTP verbs and their meaning a lot more than today. At least I don't seem to get dragged into debates on the virtues of PUT vs. POST, or using PATCH for a simple update API. If you use graphql, everything is a POST anyway. Much like SOAP back in the day. It's all just different ways to call stuff on servers. Remote procedure calls have a long history that predates all of the web.
- pixl97 4y ago
  I feel not obsessing about the meanings of HTTP verbs can, has, and will lead to security incidents and interoperability issues between middleware. Specifications where everyone gets to pick and choose different behaviors is a nightmare.
  - int_19h 4y ago
    The obsession with fine-grained distinctions may be gone, but GET/POST is still relevant when talking about caching etc.
- 4y ago