Hacker News Reader

Comment by asattarmd | Hacker News Reader

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 https://google.com/search<some-special-character><query> 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.

View on HN

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

SEARCH can have a request body.

Many systems limit the length of the URL, so this is significant.

So can POST. It's entirely redundant

From reading the article, one of the key items addressed by HTTP Search is caching. POST requests are usually not safe to cache

Is search safe to cache though?

It would definitely heavily depend on the dataset you're querying... Very little value in cached search results if you're searching through time-sensitive data such as logs or other live-datasets.

Most datasets I've searched also has a concept of permissions, so person a couldn't be served the same cached result as person b... I think search can't be cached at the http level either, its too heavily dependent on the data you're searching through so you'd have to implement it in the application anyway.

the article does make a good point though: a `get` request that supports a `body` would be nice, and thats pretty much all they're arguing for with the `search` verb.

The normal cache controls apply, so you can make it as safe as you need.

Verbs specify safety/idempotency guarantees for API-blind middleware, as well as whether (if either applies) a body needs taken into account; POST is not idempotent, SEARCH/QUERY is safe, and therefore also idempotent, but differs from GET in that that guarantee is body-specific.

Might as well just say "ok now GET can have body" instead of all that noise

Won’t retroactively change things that support GET to support GET-with-body. A new verb makes it much more likely that anything that supports the verb supports the desired semantics.

(Of course, you could instead bump the HTTP version for support of GET-with-body, but given how HTTP/2 and HTTP/3 are defined in terms of HTTP/1.1, you’d need three new versions of HTTP for a change to core verb semantics. A new verb, again, is far simpler.)

The limit of a GET request's length is at least several K on most systems I've used, so it's rarely an issue.

That's not as much as you might think.

There's a reason elasticsearch accepts POST

But what exactly is the difference between POST and SEARCH? Both include the request parameters in the body, so they would be obscured from the user. Unless they aren't, in which case it is a matter of the choices made in the implementation.

Is it implied idempotency and the lack of a confirmation dialog when the user reloads the page?

Cachability, perhaps. You cannot cache a post, but may be able to cache a search or query verb.

If I send a request body with GET, what modern systems would even have a problem with that? Is there some caching middleware somewhere that I've never heard of or just ignored that will screw it up?

If there was a GET-with-body http verb I'd probably use it at one point or another, but I often wonder where plain GET would start blowing up if I just used it for that.

Honestly, I think rest is a mess, and that everything should just be POST with no values in the url at all.

GET with a body is pretty useless because the standard doesn’t allow the body to affect the results. So, proxies, browsers, etc. are free to ignore the body when caching results.

Quick workaround: GET /search?key=$hash(body)

Reminds me Google Maps: GET /search?pb=$protobuf_to_string.

even though most servers support it AFAIK, many clients don't. Many will even silently discard the body when sending a GET request.

The primary use case of SEARCH is programmatic, e.g., making complex requests to a search API in order to render results. Those are API requests, they're not being shared around.

The proposal has changed the name to QUERY, just yesterday.

> One advantage of GET is I can just copy the URL and share it.

Often but not always.

The article is wrong when it says message bodies for GET are defined to be meaningless. They are in fact just not defined to be meaningful, which is very much not the same thing.

Nothing in the spec for GET blocks using message bodies with it. Elastic search famously uses(used?) bodies with GET requests.

unless you control every hop between client and server, GET bodies can be arbitrarily dropped, and can't be relied upon

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.

That would unfortunately break the internet as a GET query without ?key=value and just ?value is perfectly reasonable.

This is why the RFC suggests you redirect to a GET like /resource/queryABCD

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.

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.

We already have a format to identify an entire request including verb and headers. It’s called HTTP.

Yes, but it can't be used as a hyperlink or typed into the browser bar.

HTTP is a two-way messaging protocol. What's being talked about here is the capabilities in hyperlinks. Totally different.

That sounds like a deficiency of browsers, not of URLs. Browsers can already make arbitrary HTTP requests, and there are some rudimentary ways to expose this in hypertext (such as forms or XHR), but there’s nothing stopping a browser from letting you dump a full HTTP request into a text field and sending it.

You're ignoring such a huge part of the HTTP specification there, like request idempotency, caching, the security model, and surely stuff I'm forgetting right now.

HTTP, at its heart, is a way to compose an action from a verb and a noun - such as "get this", or "update that". The request method, or verb, is intertwined with the URI, or resource, the noun - together, they form the action the user agent intends to carry out. "GET /foo" is entirely distinct from "POST /foo", and there are lots of considerations why it has been implemented like that. I cannot recommend reading the spec (or letting ChatGPT summarise it for you) enough, it will really make more sense.

Having said all that, I know what situations you are referring to - say, issuing a PATCH request with an HTML form, or circumventing some redirect bug with a POST request. Still, all of those problems hint at some other, more general issue, and solving such inconvenience would come at the price of a completely broken HTTP specification. Protocols like email, or HTTP, have only been around for so long because they were designed elegantly and carefully. Let's not break that for convenience' sake :)

Believe me, I've read the spec as I've wound up implementing HTTP servers from scratch multiple times a couple decades ago.

None of this suggestion is about incorporating all of HTTP's functionality. It's just the situations that you say you know I'm referring to -- verbs, things like authorization headers, a POST payload.

Expanding the functionality of hyperlinks wouldn't break anything about HTTP. It would just allow more requests to be defined in a single line of text (a hyperlink), rather than requiring lines of JavaScript to define. The browser (or cURL or whatnot) would convert the link to the actual HTTP request. Zero changes to HTTP.

Well. Hyperlinks are part of the spec though, and if you modify them and expect clients to know how to deal with that, you’ll need to modify the specification, and that implies you need to define how those changes affect caching, Proxies, and the security model. There’s a pretty good reason you send credentials in a header, not the URL. What’s my browser supposed to show in the history?

What you’re looking for is a browser extension, not a haphazard URI change.

you can call it https+rpc and be formatted like

https+rpc:||news.ycombinator.com|reply?id=36096485&goto=item%3Fid%3D36095032%2336096485#method=PUT#H-Accept=text/html

with | instead of / to workaround this site encoding

Sounds like what curl does. Maybe curl:{curl commandline}

This is an interesting idea for a browser extension. Maybe needs a change in name from URL/URI. Could be a DURI, Discrete Universal Record Interaction. Just spitballing. You could share one-liners similar to how one might share curl command-lines but expect them to work in multiple environments.

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

it’s extremely to share urls needing auth with people who have the same access levels as you, such as in your company

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.

It’s not a “no you can’t” just because you know of some exceptions.

And even then, they are still correct while you are not. You can copy the GET url even if it ultimately it requires authentication in a way that you can’t do it all for a POST request.

Reply on news.ycombinator.com