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

RFC 10008: The new HTTP Query Method

rfc-editor.org

Post reply on HN
Print view View original

161–170 of 189 posts

Re: RFC 10008: The new HTTP Query Method

#161

Post by pwdisswordfishq »

ekr____ wrote: post #42
rhplus wrote: post #11

Earlier quoted context omitted.

Someone has an ambiguous bet predicting when RFC 10000 will be published, but the numbers went straight from 9998 to 10008. No-one wins! https://manifold.markets/CollectedOverSpread/when-will-rfc-1...

RFC 10000 will not be published. They're just going to skip past the number. https://mailarchive.ietf.org/arch/msg/tools-discuss/EpoQcVt_... RFC #s are issued sometime before publication, so they can come out out of order. I would expect 9999, 10001, etc. to show up eventually.

Damn, I was so looking forward to see Robert Downey Jr. as the TLS handshake

Re: RFC 10008: The new HTTP Query Method

#162

Post by Zardoz84 »

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

I work with a custom own maded web framewrok for Java (from before Spring was a thing!). A funny thing it's that treats GET and POST petitons identical when try to recover parameters from the petitions. So GET and POST get parametertes from URL and from BODY. And this made some weird bugs many years ago, when in some case, we got repeated parameters in URL and BODY, trigering the framewrok to think that must put it on a List and pass it to the service method.

Re: RFC 10008: The new HTTP Query Method

#163

Post by CodesInChaos »

ralferoo wrote: post #65
CodesInChaos wrote: post #36

Earlier quoted context omitted.

The browser can simply store a collision resistant hash (e.g. SHA-256) of the body, if it wants a smaller cache key. I can't really think of any caching related attacks that don't equally apply to a query parameter. Generating a unique 30 character query parameter is just as easy as generating a 30 MB request body, if you want to flood the cache.

Not necessarily that simple, as you'd have sort all the input parameters to maintain a useable cache key. Not especially difficult, but if the data is large and so re-allocation and sorting is required, then you're starting to open up the attack surface where bugs might have been introduced.

I think the only sane approach for caching comparing if the body is identical and not apply any content type specific transformations. It's the safest choice, and the cache not being effective in some edge cases isn't a big deal. The client can always canonicalize the data itself, if it matters for its use-case.

Even if the spec says that different representations are equivalent, it's quite common for applications to treat them differently. For example field ordering in json objects is supposed to not matter, but some serializers care if a type discriminator is the first field.

Re: RFC 10008: The new HTTP Query Method

#164

Post by tempfile »

diroussel wrote: post #96
tempfile wrote: post #49

Earlier quoted context omitted.

Depends whether your form submission should expect side effects or not. Most forms submissions have side effects. If the effect is truly idempotent, wouldn't PUT be a better verb? That is also supposed to be idempotent.

GET and QUERY are both idempotent.

I know, but neither GET nor QUERY may have side effects.

Re: RFC 10008: The new HTTP Query Method

#165

Post by tempfile »

echoangle wrote: post #73
tempfile wrote: post #49

Earlier quoted context omitted.

Depends whether your form submission should expect side effects or not. Most forms submissions have side effects. If the effect is truly idempotent, wouldn't PUT be a better verb? That is also supposed to be idempotent.

You can’t use PUT as a form action though.

I always forget this, because it makes no sense. Fair enough!

Re: RFC 10008: The new HTTP Query Method

#166

Post by imtringued »

acabal wrote: post #148
MBCook wrote: post #122

Earlier quoted context omitted.

What’s the use case for that?

Because if HTTP is the language of the web, then HTML forms are how humans speak that language to computers. Right now we humans can only speak GET and POST. In other words, right now if a human wants to DELETE a widget, the human has click on an HTML form to `POST /widgets/123/delete` - i.e. use an incorrect verb on an incorrect URL/object - or use some other workaround like smuggling a special `_method=DELETE` vari…

Things like that are why it's completely unreasonable to expect websites to work without first party Javascript. Utterly basic and mundane functionality is gated behind Javascript.

Building the mundane in the absence of JavaScript isn't some small thing you can build. It's going to require you to rebuild your entire site around the idea. Things like a searchable dropdown will now turn a single page form into a horrifying multi page mess where you get sent to a page for just the dropdown and the search box and selectable options, which then send you back to the original form. That is going to require you to store a lot of the form data on the server to keep track of what you entered across pages rather than let the browser do its thing.

The noscript crowd should have lobbied for a better HTML instead of rallying against JavaScript.

Re: RFC 10008: The new HTTP Query Method

#167

Post by account42 »

Joker_vD wrote: post #133
spockz wrote: post #130

Earlier quoted context omitted.

Not freely. It is idempotent, not safe. So it still can have serious load consequences.

Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.

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.

Re: RFC 10008: The new HTTP Query Method

#168

Post by speleding »

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…

I like the proposal, but I agree they could have sold it better.

This is basically a GET request that can have a body. I've found myself in need of that more than once when I did not want huge URLs with encoded data showing up in logs. Using POST request there is not appropriate because it signals data could be modified (i.e. cannot be sent to read-only instances). I guess modifying the spec to allow GET to have a body would pose too many problems.

Re: RFC 10008: The new HTTP Query Method

#169

Post by sablekit »

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…

[flagged]
Post reply on HN