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

41–50 of 79 posts

Re: Upcoming new HTTP QUERY method

#41

Post by n00bskoolbus »

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…

Yeah it's already created confusion for me. I read it as essentially a side effect free request with a request body. Not that the data behind it was necessarily immutable but that the query didn't do any mutations.

Re: Upcoming new HTTP QUERY method

#42

Post by derefr »

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…

And, indeed, this has been done many times, by e.g. WebDAV (methods COPY, LOCK, MKCOL, MOVE, PROPFIND, PROPPATCH, UNLOCK).

Re: Upcoming new HTTP QUERY method

#43

Post by pdonis »

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 the database is mutated in between by someone else.

All "idempotent" actually means is that successive identical requests must induce the same change in the server's state due to the request itself. In the case of verbs like GET and QUERY, that is trivially true since they induce no change in the server's state at all. But the content of the response can of course change due to other events happening on the server. If "idempotent" required that not to happen, no request could ever be guaranteed to be idempotent.

Re: Upcoming new HTTP QUERY method

#44

Post by dragonwriter »

capableweb wrote: post #35
clairity wrote: post #31

Earlier quoted context omitted.

either extension method seems a lost cause, given that most browsers/web servers don't fully support the 7 existing http verbs, even with decades to do so.

> don't fully support the 7 existing http verbs 9 to be precise (RFC 7231 defines GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, RFC 5789 defines PATCH). Some of those are not commonly used because of various security vulnerabilities that have been discovered over the years (see https://www.kb.cert.org/vuls/id/867593 , https://www.kb.cert.org/vuls/id/288308 , https://www.kb.cert.org/vuls/id/150227 ) for some…

> > the 7 existing http verbs

> 9 to be precise

You are off by 30:

https://www.iana.org/assignments/http-methods/http-methods.x...

Re: Upcoming new HTTP QUERY method

#45

Post by darau1 »

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've used VIEW for this kind of thing. I don't even know what VIEW is for

Re: Upcoming new HTTP QUERY method

#46

Post by akersten »

tmp_anon_22 wrote: post #19
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 think this was a situation where either choice (extend GET, create QUERY) was less then ideal but at least if you create a new namespace in QUERY 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.

> 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 healthier web if these dinosaur machines got broken once in a while.

Re: Upcoming new HTTP QUERY method

#47

Post by anyfoo »

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…

I guess that they purposefully did not use JSON or any other widely used format to avoid giving the appearance that that format is required or encouraged.

As for copying/sharing links, I think that was covered in another discussion above: Just like with POST, it's likely just not intended to do QUERY requests via links or through the URL bar.

Re: Upcoming new HTTP QUERY method

#48

Post by teen »

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…

Seems nice to me.

Re: Upcoming new HTTP QUERY method

#49

Post by hakre »

zamadatix wrote: post #21
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.

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

Just as a small remark, HTTP protocol standards do - or have at least - considered URL input so far in a wider, client-side meaning. Some details are left for the clients, e.g. it differs across browsers how certain URL characters are interpreted when entered into the URL bar (or on the command-line, e.g. with curl(1)).

Apart from that, HTTP URLs are part of the same HTTP standard, aren't they?

Re: Upcoming new HTTP QUERY method

#50

Post by jmull »

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…

Edit: never mind, my response was redundant by the time I finished it.
Post reply on HN