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

21–30 of 131 posts

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

#21

Post by asattarmd »

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 smart enough to treat only https://google.com/search as the URL and anything after that as the body. The complete "URL" can be big and shared anywhere else.

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

#22

Post by hartator »

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…

Yes, that’s also lost when you do POST. Which is by design though. A HTTP Search seems like only drawbacks.

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

#23

Post by 2h »

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.

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

#25

Post by AtNightWeCode »

time0ut wrote: post #9
AtNightWeCode wrote: post #5

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

Many logging systems exclude query parameters from the logging by default. It is also fine to include PII data in the logs as long as they are handled correctly and deleted after 30 days. But I have got burned by this problem as well. Like people using PIIs for identifiers.

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

#26

Post by candiddevmike »

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.

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

#27

Post by dragonwriter »

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

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

#28

Post by dragonwriter »

tkiolp4 wrote: post #7

Wouldn’t be enough to “extend” GET so that it supports a body payload as well?

No, because that would make GET not-cachable by URL alone, which breaks systems that rely on the fact that it is.

A new method doesn’t break existing systems.

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

#29

Post by dragonwriter »

ThaFresh wrote: post #14

being from 2021, I guess this one didnt pan out

Its still actively being worked (the most recent workgroup draft, and IIRC several of the internet drafts since the posted one, names it QUERY, SEARCH as a name for thr verb is probably dead) though, yes, the particular 2021 draft didn’t get adopted as anything more.

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

#30

Post by johngalt_ »

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.

They are obviously talking about public urls.
Post reply on HN