6 ms·
I wonder if HTML forms will add support for QUERY: <form action="..." method="query"> This would avoid the annoying re-submission warnings you're getting
by CodesInChaos 4mo ago
I wonder if HTML forms will add support for QUERY:
<form action="..." method="query">
This would avoid the annoying re-submission warnings you're getting if you refresh a page that was returned by a POST form submission, since QUERY is required to be idempotent.
- 100ms 4mo agoForms, HTTP implementations, public API surfaces, and all for what exactly. Introducing a new verb for this feels profoundly misplaced
- jagged-chisel 4mo agoIdempotency is an important attribute for correctness. Yep, you can document that POSTing to $ENDPOINT is idempotent, but you can't communicate that to caching layers throughout the network. QUERY, by definition, is idempotent and cacheable.
- jnewton_dev 4mo ago[flagged]
- inigyou 4mo agoLarger scales like what? I expect that everywhere you currently cache GETs you can cache QUERYs. But does caching GETs work at scale?
- resters 4mo agoGreat point. I wish more people realized that intuitively.
- alpinisme 4mo agoAt least support - or lack thereof - for a new verb is unambiguous (compared to changing the semantics of GET)
- ctdinjeu7 4mo ago[flagged]
- CodesInChaos 4mo agoWhere does HN use POST for safe operations? I can't think of any. Comment submission isn't safe, so QUERY can't be used there. And it doesn't suffer from the problem anyways, since HN returns a 3XX on successful submission, so refreshing doesn't show a warning.
- bob1029 4mo agoThis is better solved with the post redirect get pattern.
- diroussel 4mo agoThat is the good old fashion workaround. But why is it better than a form causing an HTTP QUERY. If we can do QUERY forms, it would be an ideal time to add JSON encoding for forms.
- CodesInChaos 4mo agoThe redirect pattern makes sense for a POST request that creates a resource, where you can then redirect to the newly created resource. QUERY on the other hand makes sense for cases where the request doesn't cause any state changes on the server, and there is no resource to redirect to.
- tempfile 4mo agoDepends 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.
- echoangle 4mo agoYou can’t use PUT as a form action though.
- tempfile 4mo agoI always forget this, because it makes no sense. Fair enough!
- diroussel 4mo agoGET and QUERY are both idempotent.
- mring33621 4mo agoHold my beer!
- tempfile 4mo agoI know, but neither GET nor QUERY may have side effects.
- amluto 4mo agoOne oddity of forms: the result of a form POST is a page that has a location (the URL) but that cannot loaded via that location. As far as I know, the fact that the page is a POST and not a GET is not stored anywhere visible to the user or to JS. And refresh works oddly. If method=QUERY were added, there would be a new variety of this weirdness.
- sheept 4mo agoAt least browsers wouldn't have to warn users that they'd be resubmitting data if they reload the page after submitting a query form, since query requests are intended to be idempotent
- amluto 4mo agoYou still get the nastiness that the Sec-Fetch-* state gets mostly trashed when you hit refresh. And someone would need to figure out how CORS preflight interacts with refresh, which is not currently an issue with POST. (The current "simple request" behavior or whatever it's called is a real mess and is the cause of a lot of CSRF vulnerabilities.)
- acabal 4mo agoSupporting 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 https://github.com/whatwg/html/pull/11347
- MBCook 4mo agoWhat’s the use case for that?
- acabal 4mo agoBecause 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` variable. This is unnatural and semantically incorrect, resulting in ugly hacks that break HTTP-level expectations like idempotency; and it also requires additional app-level logic to process. Meanwhile a machine is allowed to simply `DELETE /widgets/123` because their interface to HTTP is not clicking on HTML forms. We humans could converse with websites in semantically correct HTTP, have clean URLs in which both REST APIs and human-facing URLs are identical without hacks, and require no extra app/framework logic, if HTML forms simply allowed all (human-relevant) HTTP verbs.
- imtringued 4mo agoThings 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.
- chrismorgan 4mo agoSee https://github.com/whatwg/html/issues/12594 https://github.com/whatwg/html/issues/12594.
- paradox460 4mo agoThey never added support for any other verbs, but it's a brave new world, so who knows
- XYen0n 4mo agoIf new method support is added, PUT should be used in this scenario.
- conorcleary 4mo agoWe do already have CALL