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

21–30 of 79 posts

Re: Upcoming new HTTP QUERY method

#21

Post by zamadatix »

laurent123456 wrote: post #7

The spec doesn't say how browsers should represent such request in the browser address bar. The nice thing with GET is that you can copy a search url, bookmark it or share it with someone, and they get back the exact same results. How would that work with a QUERY method?

I'm not sure it makes sense for an HTTP protocol method standard to describe how browsers should allow it's input in the URL bar - two very different standards realms.

That said you should be able to trigger any custom HTTP request your browser support via pasting/bookmarking a `data:` or `javascript:` construction if you really want. As of now the URL bar is GET only when you enter a URL.

Re: Upcoming new HTTP QUERY method

#22

Post by divbzero »

freedomben wrote: post #13
divbzero wrote: post #6

Is GET with a request body impractical at this point? It has historically been frowned upon [1] but is it really too late to change that convention? [1]: https://stackoverflow.com/questions/978061/http-get-with-req...

I've seen this done a few times and in most of those cases I agreed it made sense. I've thought about this myself a few times too. But it does lead to unexpected behavior. Users are trained to copy/paste links and send them. If the body only included stuff like auth tokens then it would be ok, but if relevant query stuff was in there (like page size, for example) that would lead to different results that would ultima…

The copy/paste URL use case is a fair consideration. The places where I’ve seen request bodies on GET requests are APIs [2] that are not seen by the end user.

[2]: https://www.elastic.co/guide/en/elasticsearch/reference/6.8/...

Re: Upcoming new HTTP QUERY method

#23

Post by oh_sigh »

elcapitan wrote: post #12

Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action. - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as que…

I wondered the same thing. Perhaps it is easier to roll out a new request method, rather than increase the scope of an existing request method. For example, a lot of extant middleware might silently drop a GET requests body, whereas they would just error out upon seeing "QUERY ..."

Re: Upcoming new HTTP QUERY method

#24

Post by _bohm »

jbverschoor wrote: post #17

Interesting that they use an sql-like query in the examples. I hope this does not mean that this will be taken as the default method of querying.. A JSON query object could've been nice as an example. How should you handle conflicting parameters (form-encoded + body)? Also, on the HTML side.. If it's extended to .. how will you be able to distinguish between the query part and the uri part? How can/should you copy/sh…

From the paragraph above:

> The non-normative examples in this section make use of a simple, hypothetical plain-text based query syntax based on SQL with results returned as comma-separated values. This is done for illustration purposes only. Implementations are free to use any format they wish

Re: Upcoming new HTTP QUERY method

#25

Post by politician »

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 the set of allowed methods can change dynamically. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are OPTIONAL."

[1] https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5....

Re: Upcoming new HTTP QUERY method

#26

Post by capableweb »

elcapitan wrote: post #12

Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action. - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as que…

> - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string

Slightly confusing, I agree. But given that neither are called just "query", and HTTP methods being usually in all caps, I think it won't be as bad. "Query component" (from URIs as specced) VS "QUERY method" should be clear enough.

Re: Upcoming new HTTP QUERY method

#27

Post by [deleted] »

elcapitan wrote: post #12

Two things that come to my mind: - why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action. - QUERY is a somewhat bad name choice, given that URL parameters are also refered to as que…

[deleted]

Re: Upcoming new HTTP QUERY method

#28

Post by aabbccsmith »

laurent123456 wrote: post #7

The spec doesn't say how browsers should represent such request in the browser address bar. The nice thing with GET is that you can copy a search url, bookmark it or share it with someone, and they get back the exact same results. How would that work with a QUERY method?

It's more for the SPA age of web apps, where we want to GET a resource from an API, but have a body in the request. For example fetching the user who is currently logged in and getting a JSON response back; it's not something you would do in the address bar.

Re: Upcoming new HTTP QUERY method

#30

Post by capableweb »

laurent123456 wrote: post #7

The spec doesn't say how browsers should represent such request in the browser address bar. The nice thing with GET is that you can copy a search url, bookmark it or share it with someone, and they get back the exact same results. How would that work with a QUERY method?

Similarly to as if you were using POST requests I'd say. So if you want the users to be able to navigate to a URL and get the same results for a POST request, you'd make the client-side read URL parameters and sculpt the POST request and send it.
Post reply on HN