Defining a new HTTP method: HTTP SEARCH

Re:Defining a new HTTP method: HTTP SEARCH by remram on Friday April 16, 2021 @10:28PM (#26841145)

I'm surprised not to see this mentioned, but Elasticsearch allows searching over GET with a request body. I believe that GET-with-body is not standard but works great in practice. It allows one to put Elasticsearch behind a proxy that only allows GET, to give customers read-only access.

[edit: or maybe it's standard but not REST-compliant?]

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by Matthias247 on Friday April 16, 2021 @10:32PM (#26841162)

GET requests are indeed not expected to have bodies, and therefore proxies will not always treat them the same way. Some might reject them, others might just pass them through (because in the end GET is also just a verb like everything else).

I wouldn't recommend anyone to rely on it to work - especially not if you are using public/cloud infrastructure.

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by SahAssar on Saturday April 17, 2021 @07:44AM (#26843524)

https://tools.ietf.org/html/rfc7231#section-4.3.1 says:

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

So it's non-non-standard but not standard either. If I understand correctly a GET with body is about as defined as a POST with body, but since it is not often used the real world support is worse. What is a lot better specified about POST is response codes, like 201 Created and (I'm guessing) content negotiation.

Browsers seem pretty strict about it though, `fetch('/', {body: ''})` gives a TypeError for me but `fetch('/', {body: '', method: 'POST'})` does not.

[ Parent | on HN ]