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

121–130 of 131 posts

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

#121

Post by kortex »

cratermoon wrote: post #62
bastawhiz wrote: post #17

Earlier quoted context omitted.

A great example of this today is GraphQL. Even if you disagree with the premise of GQL, you can understand how you can have complicated filtering and sorting logic, and conditional expansion of nested resources. For a nontrivial data model, you may want to select only a minimal number of fields on each nested resource. Having lots of different variants of the same endpoint to serve the same query with different shape…

I knew someone would bring up GraphQL, as I consider it a sort of way to present a database schema in JSON, so of course it would result in complex SQL-like queries. I understand why it works for Facebook, but it's not something I've ever reached for to solve any programming problem I've had.

It's absolutely awesome for implementing any kind of faceted search inside of a web application. Generating reports, finding resources, and of course social media do this sort of operation all the time. Gql makes it way cleaner and more efficient than GET this, parse it, POST a query, GET more things.

If you aren't in those spaces it probably seems unnecessary.

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

#122

Post by Dylan16807 »

Beldin wrote: post #54
time0ut wrote: post #9

Earlier quoted context omitted.

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.

But a new HTTP method would require an update to the middle boxes... if you're doing that, you could also consider updating them to avoid the issue you described. Overall, I'm not necessarily inherently against new HTTP methods. If equipment that is supposed to be transparent to HTTP isn't, should be solved elsewhere, not by a new HTTP method.

There's no button you can press to get all middleboxes updated.

It's better to fail on the ones that slip through the cracks than to leak data. And the failure alerts people that updates are needed here.

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

#123

Post by poisonborz »

BugsJustFindMe wrote: post #105

> GET requests ... can't have a request body. It's not specifically banned, but it is defined as being completely meaningless This is widely believed but false. And repeating it leads me to believe that the author is not careful enough to create new standards. They are just not defined to be meaningful, which is not the same thing. In fact the standard says that sending a message body with a GET request should not (s…

As other commenters pointed out, support is spotty and it's generally a greyzone. A new verb (I'd also support "QUERY") would clarify things.

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

#124

Post by 9dev »

crazygringo wrote: post #59
9dev wrote: post #53

Earlier quoted context omitted.

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 carr…

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 all…

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.

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

#125

Post by akvadrako »

BugsJustFindMe wrote: post #105

> GET requests ... can't have a request body. It's not specifically banned, but it is defined as being completely meaningless This is widely believed but false. And repeating it leads me to believe that the author is not careful enough to create new standards. They are just not defined to be meaningful, which is not the same thing. In fact the standard says that sending a message body with a GET request should not (s…

But it doesn't actually work in many browsers.

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

#126

Post by Too »

fiddlerwoaroof wrote: post #113
NoMoreNicksLeft wrote: post #110

Earlier quoted context omitted.

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 everythi…

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)

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

#127

Post by Too »

wizofaus wrote: post #101

One of the user cases listed - being able to send a large body of data to a server for it to encrypt (though it could be any sort of transformation, e.g. reformatting, encoding, format conversion, or even operations like "spell check" etc.) strongly suggests to me we don't need a new verb, but should simply redefine the expected behaviour for GET requests for when they do or don't have a body - even if it means there…

By adding the new verb, it implicitly formalizes that body in GET should not be used. Previously it was allowed, although not always expected.

This may be a good thing and it could also be a bad thing if middleware starts relying on this new expectation and break old applications that previously assumed get bodies to be passed through.

They should clarify the expected behavior of GET bodies more explicit, whether it is allowed or not doesn’t really matter, as long as it is crystal clear.

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

#128

Post by slondr »

crazygringo wrote: post #56
slondr wrote: post #45

Earlier quoted context omitted.

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.

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

#129

Post by tedyoung »

hcarvalhoalves wrote: post #93

Right now, you have two main options: Use a GET, and squeeze all the parameters you need in the URL or headers somewhere Use a POST, and have the request considered as unsafe & uncacheable Third option: you POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached. Wanting a special method for search hurts the conceptual integrity of HTTP, whe…

> POST or PUT to a resource representing the search, then you’re free to redirect and subsequently GETs of this resource can be cached.

But that only means that specific instance of the search query is cacheable, not the search query itself, no? I presume the POST would create a new identifier for the resource, so that yes, that specific resource is cacheable. (Even if the server says "oh, I've just seen this POSTed query, let me return the same resource ID", another client will still have to POST to the server, a non-cacheable action.)

The idea of cacheable isn't just by the server, but by anything in between the client and the resource. By using QUERY, the query itself can be cached.

Post reply on HN