Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Defining a new HTTP method: HTTP Search (2021)

httptoolkit.com

Post reply on HN
Print view View original

31–40 of 131 posts

Re: Defining a new HTTP method: HTTP Search (2021)

#31

Post by dragonwriter »

candiddevmike wrote: post #26
asattarmd wrote: post #21

One advantage of GET is I can just copy the URL and share it. The article makes no mention of that. While I love the proposal (apart from the name, I can see the SEARCH verb being used for something that's not search), they should also address the URL share-ablity aspect. Something like " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

Related, I wish there was a more standard way to include things like verb and headers in a URI. I hacked an implementation that parses /something#a:b&c:d to set the headers a and c, I was thinking for verb I could do https+get.

verbs don't identify a resource, so why would they be in a URI?

A separate format to serialize a request spec is a good idea, sure, but it is a distinctly different thing than the URI of the resource referenced by the request.

Re: Defining a new HTTP method: HTTP Search (2021)

#32

Post by buildfocus »

mlhpdx wrote: post #24
Spivak wrote: post #2

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

Yep, I’ve already implemented QUERY. Sorry SEARCH.

They're effectively the same I think - this post is from 2021 but a later version of the same draft renamed the concept to QUERY.

Re: Defining a new HTTP method: HTTP Search (2021)

#33

Post by nerdponx »

dragonwriter wrote: post #31
candiddevmike wrote: post #26

Earlier quoted context omitted.

Related, I wish there was a more standard way to include things like verb and headers in a URI. I hacked an implementation that parses /something#a:b&c:d to set the headers a and c, I was thinking for verb I could do https+get.

verbs don't identify a resource, so why would they be in a URI? A separate format to serialize a request spec is a good idea, sure, but it is a distinctly different thing than the URI of the resource referenced by the request.

Is that not just the HTTP 1.1 format? It's a perfectly readable plain text format.

Re: Defining a new HTTP method: HTTP Search (2021)

#35

Post by rcme »

Raqbit wrote: post #15
montroser wrote: post #3

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

Middle boxes can arbitrarily limit the request URL size in certain cases.

Sure, but in the times of encrypted traffic, the only middle boxes capable of limiting the query should be ones explicitly added by the service owner.

Re: Defining a new HTTP method: HTTP Search (2021)

#36

Post by ivan_gammel »

2h wrote: post #23
asattarmd wrote: post #21

One advantage of GET is I can just copy the URL and share it. The article makes no mention of that. While I love the proposal (apart from the name, I can see the SEARCH verb being used for something that's not search), they should also address the URL share-ablity aspect. Something like " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

> One advantage of GET is I can just copy the URL and share it. no, you cant. if the server requires any headers such as Authorization or Cookie, this method will fail.

Typical scenario is to redirect to login and after successful authentication return back to the requested URL, so the method doesn’t fail if server is implemented correctly.

Re: Defining a new HTTP method: HTTP Search (2021)

#37

Post by imnotjames »

AtNightWeCode wrote: post #20
insanitybit wrote: post #6

Earlier quoted context omitted.

> I don't see any problems with large query params. Most servers will reject URLs after a certain size, 4-8KB.

A query of that size will likely not benefit from a GET anyway so use a POST.

Sure except POST has its own set of issues - like not being cachable. But SEARCH or QUERY can be cached safely!

Re: Defining a new HTTP method: HTTP Search (2021)

#38

Post by austin-cheney »

dragonwriter wrote: post #27
montroser wrote: post #3

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

Funny you should say that: https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-m...

I understand the benefits of QUERY over GET because GET is expected to return a resource in the response. Why not just use POST though? Send a post message to a server asking to conduct a search and sending the results of that query in the response?

Re: Defining a new HTTP method: HTTP Search (2021)

#39

Post by graypegg »

asattarmd wrote: post #21

One advantage of GET is I can just copy the URL and share it. The article makes no mention of that. While I love the proposal (apart from the name, I can see the SEARCH verb being used for something that's not search), they should also address the URL share-ablity aspect. Something like " rel="nofollow">https://google.com/search where query can be arbitrarily large (>2000 URL length restriction) and the browser is sm…

Guess that needs to be different than the ? query params. I wonder if you could use ?key=value as your signal for GET, and ?value as your signal for SEARCH. I think it's up to the service to parse the string that comes after ? in a URI so maybe that's a way to go.

Re: Defining a new HTTP method: HTTP Search (2021)

#40

Post by crazygringo »

dragonwriter wrote: post #31
candiddevmike wrote: post #26

Earlier quoted context omitted.

Related, I wish there was a more standard way to include things like verb and headers in a URI. I hacked an implementation that parses /something#a:b&c:d to set the headers a and c, I was thinking for verb I could do https+get.

verbs don't identify a resource, so why would they be in a URI? A separate format to serialize a request spec is a good idea, sure, but it is a distinctly different thing than the URI of the resource referenced by the request.

I'm pretty sure you know what the parent means.

Forget about what acronyms stand for. The thing that hyperlinks point to and you can type in your browser bar is called the URL or the link.

And the point is that being able to specify a verb and headers in a link would be super useful in certain situations.

Continue to call it a URL or URI and just change the "R" in those from Resource to Request, semantics problem solved. Or invent a new URA where "A" stands for "action" and it's a valid hyperlink. The naming of it is the least important part here.

Post reply on HN