Defining a new HTTP method: HTTP Search (2021)
httptoolkit.com
Defining a new HTTP method: HTTP Search (2021)
1–10 of 131 posts
Re: Defining a new HTTP method: HTTP Search (2021)
#2See also QUERY, imho a better name than SEARCH which is semantically a GET but with a request body -- it's cacheable!
https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-meth...
Re: Defining a new HTTP method: HTTP Search (2021)
#3This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.
Re: Defining a new HTTP method: HTTP Search (2021)
#4This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.
QUERY would be more compatible with WebDAV as the would be no confusion. The relevant compatibility is with middle boxes like proxy servers that mostly already forward SEARCH but would block QUERY.
Re: Defining a new HTTP method: HTTP Search (2021)
#5Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
Re: Defining a new HTTP method: HTTP Search (2021)
#6Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
> I don't see any problems with large query params.
Most servers will reject URLs after a certain size, 4-8KB.
Re: Defining a new HTTP method: HTTP Search (2021)
#7Wouldn’t be enough to “extend” GET so that it supports a body payload as well?
Re: Defining a new HTTP method: HTTP Search (2021)
#8Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
> I don't see any problems with large query params. Most servers will reject URLs after a certain size, 4-8KB.
This is correct, and one only needs to consider the impact of large or unlimited length urls on server memory consumption per request to see that a relatively small limit is desirable and even necessary.
Re: Defining a new HTTP method: HTTP Search (2021)
#9Or just use GET since it already works. I don't see any problems with large query params. You can also split the search into a POST request and a GET request for the result.
A situational issue that I've run into a number of times with GET is various middle boxes inadvertently logging sensitive data that was in the query string of a GET. By sensitive data, I mean PII and CU information. While we have used POST to side step the issue, it'd be nice if there was a more appropriate method.
Re: Defining a new HTTP method: HTTP Search (2021)
#10Many people seem to be unenthusiastic about it because the limitation on query strings are usually large enough.
I personally like this addition, because it no longer requires all queries be shoehorned into query strings. You can use any syntax you like, be it SQL or GraphQL etc.