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

The new HTTP QUERY method explained

kreya.app

Post reply on HN
Print view View original

141–150 of 179 posts

Re: The new HTTP QUERY method explained

#141

Post by 1vuio0pswjnm7 »

Three different definitions of the hypertext transfer protocol (HTTP). Choose one

1. What the most popular HTTP servers actually accept

2. What the most popular HTTP clients actually send

3. What the RFC "standard" says

Personally I choose #1. I don't use the most popular HTTP clients

For example, under definition #1, I can do HTTP/1.1 pipelining with POST

The RFC "standard" often comes after the software implementation(s); most RFCs document what's already in use on the internet. As the selection of software expands, some competent software authors trying their best still often struggle to conform to RFCs. Go figure

To me, the source code of the most popular servers in use is the standard

Re: The new HTTP QUERY method explained

#142

Post by em-bee »

bellowsgulch wrote: post #136
ramon156 wrote: post #37

"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way

So a POST with explicit caching semantics?

no, a POST that is idempotent. caching is an optional side benefit.

Re: The new HTTP QUERY method explained

#143

Post by darig »

nesarkvechnep wrote: post #111
EnnEmmEss wrote: post #69

Earlier quoted context omitted.

Using GET with a Body doesn't work if you try using it in the browser with JS fetch for example[1]. Additionally, a lot of existing web servers by default ignore GET requests with a body. The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET reques…

There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.

[dead]

Re: The new HTTP QUERY method explained

#144

Post by lmariscal »

austin-cheney wrote: post #119

It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission. Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.

a 35+ year old text-based protocol with 3 major variants (two of them supporting binary frames), and which is used to communicate most of the internet

yeah, I also don't get the hype, let's go back to everyone declaring their own communication protocol

Re: The new HTTP QUERY method explained

#145

Post by topham »

Ghoelian wrote: post #127
topham wrote: post #104

Earlier quoted context omitted.

So, I need to update all the tools to support QUERY, or I need to update all the tools to support GET/body. So, either way, I need to update all the tools. Just fix GET.

The point is that if you do that, you end up with lots of undefined behaviour in existing software that has not been patched yet. If you make it a whole new request method, existing unpatched software should just respond with "Method not allowed".

Which means you have to structure everything around multiple scenarios anyway.

Re: The new HTTP QUERY method explained

#146

Post by topham »

Yokohiii wrote: post #122
topham wrote: post #101

Earlier quoted context omitted.

Fixing GET would be easier. And yes,it would be fixing a flawed interpretation of what should be implemented.you are, by definition GETting something. Tools dropping body from GET by default are violating the spec today. Rules configured to drop it are just that, temporarily configured constraints readily modified. Adding QUERY will make it unpredictable in effectively the same manner as GET/body. It'll take even lon…

> Fixing GET would be easier. I disagree. I think the adoption (or dismissal) of QUERY will show. First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose. It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http c…

Browsers won't.

No, really, they simply won't implement it.

Re: The new HTTP QUERY method explained

#147

Post by Rapzid »

thewisenerd wrote: post #40
Rapzid wrote: post #34

Body is already optional with GET. Proxies aren't supposed to touch it or assign meaning to it; it's between the client and the end server. A whole new method whose semantics don't really fit with the others is.. An odd way forward.

semantics become extremely relevant when "proxies" start caching.

A lot of the RFCs are flavored by the lack of https and prevalence of forward proxies run by the ISPs to improve perceived speed and reduce their network loads.. Back in the day.

By my estimation, that's why they explicitly call out only the client and origin can know what a GET body means; proxies should forward as-is and ignore.

Those days of ISP forward http proxies are gone, but those semantics are still fine; the body means what the origin and client agree it means.

Re: The new HTTP QUERY method explained

#148

Post by Rapzid »

lightningspirit wrote: post #135
degamad wrote: post #82

Earlier quoted context omitted.

> ... unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. You left out the important part.

How does the origin server indicate that?

In or out of band. ie an API.

Re: The new HTTP QUERY method explained

#149

Post by Yokohiii »

topham wrote: post #146
Yokohiii wrote: post #122

Earlier quoted context omitted.

> Fixing GET would be easier. I disagree. I think the adoption (or dismissal) of QUERY will show. First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose. It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http c…

Browsers won't. No, really, they simply won't implement it.

Okay, great.

Re: The new HTTP QUERY method explained

#150

Post by veltas »

flanked-evergl wrote: post #117
veltas wrote: post #96

The other issue with adding a separate supported way to do what people did with GET+body is that we will probably see servers slowly drop support for the GET+body approach when QUERY gets widespread support/usage, and then a ton of other stuff will break. Unless you're really going to improve things or the existing practices are really too painful, standards should follow convention. Even though GET+body is not handl…

> Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard. Is there some research or study that you base this claim on? What is the reasoning? Can you elaborate?

With standards it helps to reconcile existing behaviour, rather than create new unproven syntax.

Likewise creating a new syntax for something that already exists means you are just adding to the heap of stuff that needs support on mainstream servers, and as I already said it will probably create compatibility issues as the old deprecated/illegal syntax is removed. This is unnecessary friction.

And really what is the advantage of a new syntax? That needs explaining.

Post reply on HN