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

Upcoming new HTTP QUERY method

datatracker.ietf.org

Post reply on HN
Print view View original

71–79 of 79 posts

Re: Upcoming new HTTP QUERY method

#71

Post by ithkuil »

shadowgovt wrote: post #56
akersten wrote: post #46

Earlier quoted context omitted.

> you can avoid arcane business logic around GET by various caches, loadbalancers, proxies, and other software that made who knows what terrible assumptions around GET payload shape. I wish standards bodies weren't afraid of angering the feet-dragging vendors who haven't had to update their shitty middleboxes in 20 years despite charging their customers through the nose for them. Maybe it would be better for a health…

It's all fun and games until it turns out your home ISP is one of those dinosaur machines and now you can't log onto HN because none of the routers you can connect to understand GET with a body.

In that case you'd be using https which doesn't get proxied. But yeah, it's all somebody else's problem until it's yours...

Re: Upcoming new HTTP QUERY method

#72

Post by qalmakka »

politician wrote: post #25
qalmakka wrote: post #15

Is it really OK to add a new method to HTTP 1.1? I think would be quite an unfortunate decision, because it would make the version numbers absolutely meaningless if all of a sudden new methods can pop up without them changing.

HTTP 1.1 makes it clear that the method mechanism is extensible [1]. Method = "OPTIONS" | "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "TRACE" | "CONNECT" | extension-method extension-method = token "The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since th…

Thanks, it makes sense now. I had the feeling I was missing something, I haven't really ever read the HTTP spec TBH so I was not aware of this.

Re: Upcoming new HTTP QUERY method

#73

Post by Macha »

contravariant wrote: post #4

Am I right in thinking that this is basically an alternative to URI query parameters? Presumably to make parsing the query and caching the results easier.

I think the biggest motivation I've seen every time GET bodies are brought up is the size limit on request bodies is normally much larger than on URIs and especially query builder type interfaces run up against this, which is why e.g. elasticsearch does this.

Re: Upcoming new HTTP QUERY method

#74

Post by wink »

pdonis wrote: post #43
hcarvalhoalves wrote: post #34

> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. I’m already seeing implementors failing at following the spec here – they will equate the QUERY method to querying a mutable database, which won’t give reproducible results, and to give reproducible results the server would need to save it. Now to make it idempotent, will be an ad-hoc deci…

"Idempotent" does not mean successive identical requests must return identical content. For example, two successive GET requests to the same URL will not return identical content if in between them the owner of the website changes the page at that URL. Similarly, if the source of the request content is a mutable database, two successive QUERY requests with the same request content will not return identical content if…

> that is trivially true since they induce no change in the server's state at all.

Have you heard about visit counters? ;)

Re: Upcoming new HTTP QUERY method

#75

Post by RealPawel »

Any reasonable system requires offset. Also, it would be nice to have a search id that allows client to fetch further records in a linear way without risking data shifts when new records get added. The last "must have" would be to have some form of ordering.

QUERY /contacts HTTP/1.1 Host: example.org Content-Type: example/query Accept: text/csv

select surname, givenname, email limit 10 offset 40 key 2eQ8m5

Re: Upcoming new HTTP QUERY method

#76

Post by pdonis »

wink wrote: post #74
pdonis wrote: post #43

Earlier quoted context omitted.

"Idempotent" does not mean successive identical requests must return identical content. For example, two successive GET requests to the same URL will not return identical content if in between them the owner of the website changes the page at that URL. Similarly, if the source of the request content is a mutable database, two successive QUERY requests with the same request content will not return identical content if…

> that is trivially true since they induce no change in the server's state at all. Have you heard about visit counters? ;)

If visit counters are considered to be changes in the server state, then servers that implement them are violating the requirement that GET requests must be idempotent.

Re: Upcoming new HTTP QUERY method

#78

Post by nokya »

I see two problems: redundancy and consistency.

After spending pages telling the reader that the query should not affect the server's state, the only example given appears to do exactly that: initiate a query and return a GET url to retrieve the results.

Either the GET request actually triggers the database request, which makes the QUERY request totally redundant, or the QUERY request relays a call to a database interpreter and the server responds with a location to retrieve the results.

Second, how would the http server know that the query is both idempotent and safe? Providing an example with SQL-like code makes it look even more like a bad joke...

I see this creates (at least) two problems and solves none. Do the authors know which problem they hope to solve?

If I had more time I'd look into their bios. Something tells me this is a typical case of "I put my name in a RFC", unless they work under the umbrella of some GAFAM who needs a new HTPP verb without disclosing why.

Re: Upcoming new HTTP QUERY method

#79

Post by hcarvalhoalves »

pdonis wrote: post #43
hcarvalhoalves wrote: post #34

> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. I’m already seeing implementors failing at following the spec here – they will equate the QUERY method to querying a mutable database, which won’t give reproducible results, and to give reproducible results the server would need to save it. Now to make it idempotent, will be an ad-hoc deci…

"Idempotent" does not mean successive identical requests must return identical content. For example, two successive GET requests to the same URL will not return identical content if in between them the owner of the website changes the page at that URL. Similarly, if the source of the request content is a mutable database, two successive QUERY requests with the same request content will not return identical content if…

I mean: I don't see the point to have a new method that still gives the same (weak and misnamed) idempotency guarantees of GET. We already have GET, and a new method isn't necessary just to pass request data.

I would rather have a method that _may_ have side-effect on the server-side, but it's actually idempotent from the client-side (as in, truly reproducible results). That already exists in the form of a PUT + some content addressing scheme, for example, but it's open to each implementation.

Post reply on HN