4 ms·

I was just working with OpenSearch's API recently, who sort of abuse the semantics of the HTTP spec by using GETs with a body to perform search queries, largely

by giobox 2y ago

I was just working with OpenSearch's API recently, who sort of abuse the semantics of the HTTP spec by using GETs with a body to perform search queries, largely to solve a similar problem. A "QUERY" message type would probably easily replace the GET with a body used by OpenSearch etc. I'd go as far as to argue thats largely what this new QUERY type is - official recognition for a "GET" request with a body. > https://opensearch.org/docs/latest/api-reference/search/ https://opensearch.org/docs/latest/api-reference/search/

BugsJustFindMe 2y ago
It's not abuse of the spec. The spec says that GET is allowed to have a body. Whether an endpoint must honor it is left undefined, and this has lead people to believe wrongly that that means endpoints are not allowed to expect it. But certainly the endpoint itself defines what it does with your requests, and that's what actually matters. QUERY is just GET once more with feeling, because people are worried about existing software that made the wrong decision about denying or stripping GET bodies and would need to be updated to allow them through, and detecting an unimplemented verb is I guess maybe simpler than detecting some middle layer being a dick and dropping your data.
- treve 2y ago
  This is not a correct interpretation of the spec, as far as I can tell. I did some more research on this + primary sources on my blog if you're interested in why and why people are confused about this: https://evertpot.com/get-request-bodies/ https://evertpot.com/get-request-bodies/
  - BugsJustFindMe 2y ago
    Your post puts a tremendous amount of weight on how you personally feel about using it across load balancers that you don't control and whatnot, but you also still acknowledge that it doesn't violate the spec. > It’s true that undefined behavior means that you as a server developer can define it Good. Agreed. Done. Someone else complying with the spec in an incompatible way doesn't make your compliance wrong. It just reduces the circumstances where it will work. But those circumstances are...well... circumstantial. And I think it's important to establish that there's a meaningful difference between "won't work as expected in certain common but not universal circumstances" and "not allowed to at all".
    - treve 2y ago
      You either didn't read what I wrote, or are homing in on the things that are ambiguous vs the things that aren't. (or I'm just a bad writer). One thing is not ambiguous: The intent, as stated by one of the primary authors of the HTTP specification has "no semantic meaning" and "is never useful to do so". You can do something different and assign meaning to the body, but it's no longer HTTP. So you are correct, it's not disallowed, just pointless. I'd also recommend you read the latest version of the HTTP spec. It's a bit more direct about this. You can disagree with the authors of the HTTP spec of course, but I'm not interested in having that argument with you.
  - deleted 2y ago
    [deleted]

by giobox 2y ago

BugsJustFindMe 2y ago

It's not abuse of the spec. The spec says that GET is allowed to have a body. Whether an endpoint must honor it is left undefined, and this has lead people to believe wrongly that that means endpoints are not allowed to expect it. But certainly the endpoint itself defines what it does with your requests, and that's what actually matters. QUERY is just GET once more with feeling, because people are worried about existing software that made the wrong decision about denying or stripping GET bodies and would need to be updated to allow them through, and detecting an unimplemented verb is I guess maybe simpler than detecting some middle layer being a dick and dropping your data.

treve 2y ago
This is not a correct interpretation of the spec, as far as I can tell. I did some more research on this + primary sources on my blog if you're interested in why and why people are confused about this: https://evertpot.com/get-request-bodies/ https://evertpot.com/get-request-bodies/
- BugsJustFindMe 2y ago
  Your post puts a tremendous amount of weight on how you personally feel about using it across load balancers that you don't control and whatnot, but you also still acknowledge that it doesn't violate the spec. > It’s true that undefined behavior means that you as a server developer can define it Good. Agreed. Done. Someone else complying with the spec in an incompatible way doesn't make your compliance wrong. It just reduces the circumstances where it will work. But those circumstances are...well... circumstantial. And I think it's important to establish that there's a meaningful difference between "won't work as expected in certain common but not universal circumstances" and "not allowed to at all".
  - treve 2y ago
    You either didn't read what I wrote, or are homing in on the things that are ambiguous vs the things that aren't. (or I'm just a bad writer). One thing is not ambiguous: The intent, as stated by one of the primary authors of the HTTP specification has "no semantic meaning" and "is never useful to do so". You can do something different and assign meaning to the body, but it's no longer HTTP. So you are correct, it's not disallowed, just pointless. I'd also recommend you read the latest version of the HTTP spec. It's a bit more direct about this. You can disagree with the authors of the HTTP spec of course, but I'm not interested in having that argument with you.
- deleted 2y ago
  [deleted]