RFC 10008: The new HTTP Query Method • Hacker News Board

Re: RFC 10008: The new HTTP Query Method

#181

Post by n11348745 » Thu, Jun 18, 2026, 9:14 PM UTC

pie_flavor wrote: post #109

simon84 wrote: post #89

This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol. HTTP is transfer protocol. It should not ever imply anything at the business level. Yes REST made it's worst mistake out if it by giving a meaning to the verb. Yes proxies rule how the body is re-interpreted in spite of the will of…

Yes this, yes that, yes the other, because proxies are in agreement with patterns are in agreement with the HTTP spec that methods exist and have semantic and functional requirements. Your 'should' seems to be discussing a hypothetical technology that is not HTTP, because HTTP has worked this way since 1997.

[flagged]

Re: RFC 10008: The new HTTP Query Method

#182

Post by Balthild » Fri, Jun 19, 2026, 2:21 AM UTC

MBCook wrote: post #122

acabal wrote: post #93

Earlier quoted context omitted.

Supporting more than GET/POST in HTML forms has been my dream for decades. There's a WHATWG proposal to do just that if you want to add your voice: https://github.com/whatwg/html/pull/11347

What’s the use case for that?

It is almost a use case in itself: to make an form in pure HTML to allow user to update/delete a resource on the server, without violating the HTTP semantics with routes like `POST /items/:id/delete`.

Re: RFC 10008: The new HTTP Query Method

#183

Post by _betty_ » Fri, Jun 19, 2026, 9:36 AM UTC

piterrro wrote: post #44

> GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decision to create a distinct method came down to historical interoperability issues and strict compliance with the core architectural definitions of HTTP. I've been sending request body along GET method for years now

what do servers/proxies do when they don't recognise the verb?

Re: RFC 10008: The new HTTP Query Method

#184

Post by spockz » Sat, Jun 20, 2026, 6:20 AM UTC

themgt wrote: post #174

account42 wrote: post #167

Earlier quoted context omitted.

Putting something in a spec does not automatically make it true. In the real world if you repeat expensive queries more than an undefined amount you get blocked or at least bot-checked.

Putting something in a spec does not automatically make it true. Terrible news for computing.

The point is that you need to take care to make the implementation of that endpoint safe. It isn’t safe magically by itself.

Re: RFC 10008: The new HTTP Query Method

#185

Post by lenkite » Sat, Jun 20, 2026, 10:43 AM UTC

MBCook wrote: post #122

acabal wrote: post #93

Earlier quoted context omitted.

Supporting more than GET/POST in HTML forms has been my dream for decades. There's a WHATWG proposal to do just that if you want to add your voice: https://github.com/whatwg/html/pull/11347

What’s the use case for that?

I don't want to write Javascript for what should be a core feature of Basic HTML forms.

Re: RFC 10008: The new HTTP Query Method

#186

Post by themgt » Sat, Jun 20, 2026, 1:58 PM UTC

spockz wrote: post #184

themgt wrote: post #174

Earlier quoted context omitted.

Putting something in a spec does not automatically make it true. Terrible news for computing.

The point is that you need to take care to make the implementation of that endpoint safe. It isn’t safe magically by itself.

Great, got it. I'll update my running "how computing works" chart with this new information:

  | implementation = reality | magic  |
  |-----------------------------------|
  | 999,999,999,971 (+1)     | 0      |

Re: RFC 10008: The new HTTP Query Method

#187

Post by lightningspirit » Tue, Jun 23, 2026, 2:15 PM UTC

100ms wrote: post #10

Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting. Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningf…

This is controlled by the (Last-Modified, If-Modified-Since) and (ETag, If-None-Match) header pairs. HTTP is stateless; it does not require any persistence. The only thing that defines kind of an optional persistence is the caching layer, for obvious reasons.

Re: RFC 10008: The new HTTP Query Method

#188

Post by robertlagrant » Tue, Jun 23, 2026, 2:26 PM UTC

codedokode wrote: post #179

robertlagrant wrote: post #173

> https://www.rfc-editor.org/info/rfc10008/#section-2.8 Having a standard way to do pagination would be extremely useful. If we could add an items (or similar) range header type that would be excellent! For example, in the HEAD response (and the QUERY response): accept-ranges: items items-length: 342 In the QUERY request: Range: items=0-9

The pagination is not always done with page numbers, sometimes there are "next" and "previous" tokens.

True. Perhaps it could be done using a Link header, although that won't give you the total number of records.

Re: RFC 10008: The new HTTP Query Method

#189

Post by spockz » Tue, Jun 23, 2026, 2:51 PM UTC

themgt wrote: post #186

spockz wrote: post #184

Earlier quoted context omitted.

The point is that you need to take care to make the implementation of that endpoint safe. It isn’t safe magically by itself.

Great, got it. I'll update my running "how computing works" chart with this new information: | implementation = reality | magic | |-----------------------------------| | 999,999,999,971 (+1) | 0 |

Why the snark? The existing methods have been around for ages. Many engineers I’ve encountered were not even aware that there was a distinction between “idempotent” and “safe” as attributes of a method and generally conflated them, using “safe” in the sense of the dictionary definition instead of the spec’s.

Elsewhere it was suggested that we can now replace POST with this query. I was trying to be cautionary because just changing the method alone will bring different behaviour. I did so in brevity because I was in a rush. IMHO, that does not call for snark.