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

31–40 of 79 posts

Re: Upcoming new HTTP QUERY method

#31

Post by clairity »

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…

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.

Re: Upcoming new HTTP QUERY method

#32

Post by bityard »

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?

In HTTP, clients are user agents and a web browser is only one kind of user agent that is specialized in fetching and displaying web pages. Like PUT and DELETE, this is clearly meant for APIs, not web pages. (Although sufficiently "advanced" web pages may make API calls.)

Re: Upcoming new HTTP QUERY method

#33

Post by bricss »

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…

GET with "Query" header + "Vary: Query" header, might be a thing to get escape from the cache dungeon

Re: Upcoming new HTTP QUERY method

#34

Post by hcarvalhoalves »

> 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 decision of each server. It seems contradictory. At this point it’s indistinguishable from a PUT on a resource that represents the query itself.

I’m not seeing the point of the new method.

Re: Upcoming new HTTP QUERY method

#35

Post by capableweb »

clairity wrote: post #31
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…

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

Some tooling goes as far as defining some of those methods as "forbidden", like what the standard for JavaScript Fetch does.

Re: Upcoming new HTTP QUERY method

#36

Post by jdlshore »

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.

The short version is that it's perfectly fine. This doesn't modify the HTTP spec, and it uses established extension mechanisms.

The long version:

RFC 7231 defines the standard HTTP methods in section 4.1. [1] Looking at it, the only methods that are required are GET and HEAD. All others are optional, and the spec explicitly calls out that additional methods may be created and registered with the IANA.

Looking closely at this RFC reveals two things:

1. It doesn't modify any of the HTTP RFCs. (There's no "Obsoletes" or "Updates" header.)

2. In section 6 of the QUERY RFC, it requests that the IANA add the new method to its registry. That follows the guidelines in RFC 7231 section 4.1.

[1] https://datatracker.ietf.org/doc/html/rfc7231#section-4.1

Re: Upcoming new HTTP QUERY method

#37

Post by dragonwriter »

oh_sigh wrote: post #23
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 ..."

> Perhaps it is easier to roll out a new request method, rather than increase the scope of an existing request method.

It’s easier to define semantics for a new method than to expect everyone to change how an existing methods is handled by all existing software.

Re: Upcoming new HTTP QUERY method

#40

Post by tomcam »

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

That has always driven me crazy

Post reply on HN