Add PUT, PATCH, and DELETE to form method attribute #11347
Conversation
Resolves: whatwg#3577 This adds `put`, `patch`, and `delete` values to the form element's `method` attribute, and alters navigation to properly handle those additional HTTP methods. It relies on a corresponding change to fetch spec, which allows `mode=navigate` fetches to make CORS requests ([fetch spec PR whatwg#1785](whatwg/fetch#1785)).
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as off-topic.
This comment was marked as off-topic.
There was a problem hiding this comment.
Just so I'm clear, your intention is to satisfy the whole proposal with this PR and whatwg/fetch#1785, right? I ask because this PR doesn't seem to make any changes to HTML's navigation machinery, and only a few small additions to the session history infra.
We should probably update the example just below this spec prose which uses "POST" as a shoddy substitute for "DELETE", which didn't exist as a valid method at the time that example was created. Could you also try and find more related examples of that same kinda thing?
| should prompt the user to confirm the operation first, since otherwise transactions (e.g., | ||
| purchases or database modifications) could be repeated.</p> | ||
| data-x="she-method">method</span> is a non-<span data-x="http-idempotent-method">idempotent</span> | ||
| method, the user should prompt the user to confirm the operation first, since otherwise |
There was a problem hiding this comment.
We should add "agent" back to this, right? Is there a reason that word was removed? Also the need for "repeated" => "duplicated" and the other elision isn't clear.
| @@ -100203,6 +100270,9 @@ interface <dfn interface>NotRestoredReasons</dfn> { | |||
|
|
|||
| <li><p><dfn data-x="she-url">URL</dfn>, a <span>URL</span></p></li> | |||
|
|
|||
| <li><p><dfn data-x="she-method">method</dfn>, an HTTP request | |||
| <span data-x="http-method">method</span>, initially set to GET</p></li> | |||
There was a problem hiding this comment.
Can we just link to Fetch's "method" definition (https://fetch.spec.whatwg.org/#concept-method) instead? That way we won't have to add a new dfn pointing to https://httpwg.org/specs/rfc7231.html#methods. Does that work?
|
|
||
| <div class="example"> | ||
|
|
||
| <p>The <code data-x="attr-fs-method">method</code> attribute can also specify the value |
There was a problem hiding this comment.
This needs to be indented by one space (you can see the exact formatting in other example blocks nearby).
Description
This adds
put,patch, anddeletevalues to the form element'smethodattribute, resolving #3577. It relies on a corresponding change to fetch spec, which allowsmode=navigatefetches to make CORS preflight requests (fetch spec PR #1785).Per the checklist, I'm refraining from pinging until implementer support is lined up and tests are written. Nevertheless I am opening this PR so that the approach can be read and validated by interested parties.
Summary of Modifications
Modifications to navigation are difficult—"Welcome to the dragon's maw," HTML 7.4 warns—but every effort has been made to ensure that this change is as precise as possible, while taking care to update terminology to match the enhanced functionality.
methodattributeIn addition to enabling additional form methods, the navigation work in particular removes the assumption in the specification that the presence of a request body (technically, a
POST Resource) implies a POST request, paving the way for the addition of increased HTTP capabilities in HTML.Details and Correctness
Here I outline exactly which lines in the specification fulfill the goals first outlined in "Support PUT, PATCH, and DELETE in HTML Forms" (Triptych Proposal #1), proposed in this comment on #3577, and favorably reviewed by WHATNOT on 2024-08-22. I certainly expect that spec experts will request modifications to this proposal—this section serves to highlight my own assumptions, in order to make the process of fixing any errors as easy as possible.
Rendering + Redirection
In short, the new methods should behave identically to the old methods with respect to response content and redirection. Response content should be rendered in the document, after following redirects. This is handled in HTML 7.4.5, which does not currently switch on
method.The only change made to this section is to set the fetch
methodbased on the new Session History Entrymethod, rather than the presence of a request resource (f.k.a POST resource).Form Data Behavior
HTML 4.10.21.3 describes what the browser should do with form data, based on the form's
methodattribute.httphttpsftpjavascriptdatamailtoIn addition to adding PUT, PATCH, and DELETE as permitted values for that attribute, this table is extended such that DELETE matches GET behavior (i.e. including form data in the URL as a query parameter), and PUT and PATCH match POST behavior.
Additionally, the form element now passes its
methodto the navigate algorithm.CORS
A fetch returns a network error if a request is made that does not comply with existing CORS requirements (i.e. the preflight fetch fails). HTML 7.4.5 will abort the navigation if this happens. This means that not only will navigation work with CORS-restricted methods, they are automatically safer for developers to use.
The only change required here is the linked fetch spec PR #1785 , which allows
mode=navigationfetches to make CORS preflight requests.Refresh and reloading behavior
HTML 7.8 directs the user agent to prompt the user before reloading navigables whose active session history entry's document state's resource is a request resource (f.k.a. POST resource). This generalizes that statement to direct the user agent to prompt the user before reloading navigables whose active session history entry's method (newly added field) is not idempotent.
User agents can, of course, choose to prompt on idempotent-but-unsafe methods like PUT as well, but this change permits them to resubmit the request automatically, as allowed by the HTTP RFC.
Additional Notes
custommethodAttributeSection 9.1 of the proposal includes a
custommethodattribute for forms, which overwrites themethodattribute. I believe this additional attribute is very important for adoption, as the existingmethod's fallback to GET on unknown values poses an unacceptable risk in many contexts.Nevertheless,
custommethodis omitted from this proposal for simplicity's sake. It can be somewhat trivially added later if this succeeds.Non-fetch link schemes
The non-fetch link schemes for PUT, PATCH, and DELETE were chosen to follow the principle of lease surprise. With respect to fetch schemes, PUT and PATCH mirror the behavior of POST, while DELETE mirrors that of GET; non-fetch schemes do the same.
Nevertheless, it clearly doesn't make a ton of sense to send a DELETE request to a
mailtolink. While I think there is likely no harm in allowing this—it's legal HTTP, the browser is already capable of doing it—I also don't think it's important, and would be fine having this be a no-op.Checklist
(See WHATWG Working Mode: Changes for more details.)
/acknowledgements.html ( diff )
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/form-control-infrastructure.html ( diff )
/infrastructure.html ( diff )
/nav-history-apis.html ( diff )