Skip to content

Add PUT, PATCH, and DELETE to form method attribute #11347

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Add PUT, PATCH, and DELETE to form method attribute #11347

wants to merge 8 commits into from
+138 −56

Conversation

alexpetros
Copy link

@alexpetros alexpetros commented May 30, 2025 •
edited by pr-preview bot
Loading

Description

This adds put, patch, and delete values to the form element's method attribute, resolving #3577. It relies on a corresponding change to fetch spec, which allows mode=navigate fetches 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.

  • Form element
    • Add PUT, PATCH, and DELETE as values for the method attribute
    • Demonstrate PUT and DELETE support with examples
    • Specify PUT, PATCH, and DELETE behavior for non-HTTP schemes
    • Initiate navigation with appropriate method
  • Navigation
    • Add "method" to Session History Entry struct (defaults to GET)
    • Update navigation to set fetch method based on Session History Entry method
    • Rename "POST Resource" to "Request Resource", and rename derivative variables
    • Rename "allowPost" to "allowUnsafe"
    • Add the ability—though not a requirement—for session restoration to re-perform idempotent requests

In 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 method based on the new Session History Entry method, 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 method attribute.

GET POST
http Mutate action URL Submit as entity body
https Mutate action URL Submit as entity body
ftp Get action URL Get action URL
javascript Get action URL Get action URL
data Mutate action URL Get action URL
mailto Mail with headers Mail as body

In 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 method to 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=navigation fetches 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

custommethod Attribute

Section 9.1 of the proposal includes a custommethod attribute for forms, which overwrites the method attribute. I believe this additional attribute is very important for adoption, as the existing method's fallback to GET on unknown values poses an unacceptable risk in many contexts.

Nevertheless, custommethod is 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 mailto link. 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

  • At least two implementers are interested (and none opposed):
    • …
    • …
  • Tests are written and can be reviewed and commented upon at:
    • …
  • Implementation bugs are filed:
    • Chromium: …
    • Gecko: …
    • WebKit: …
    • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
    • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
  • Corresponding HTML AAM & ARIA in HTML issues & PRs:
  • MDN issue is filed: …
  • The top of this comment includes a clear commit message to use.

(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 )
/interactive-elements.html ( diff )
/nav-history-apis.html ( diff )

This was referenced May 30, 2025
Open
Open
@AramZS

This comment was marked as duplicate.

Sign in to view
@Fake-User

This comment was marked as off-topic.

Sign in to view
@domfarolino domfarolino added addition/proposal New features or enhancements topic: forms labels Jun 10, 2025
domfarolino
domfarolino reviewed Jul 14, 2025
View reviewed changes
Copy link
Member

@domfarolino domfarolino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@alexpetros alexpetros force-pushed the put-patch-delete-forms branch 2 times, most recently from 0d17926 to f4fc873 Compare August 3, 2025 00:36
@alexpetros
Add PUT, PATCH, and DELETE to form method attribute
50a0414 
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)).
@alexpetros
Fix indentation
a925745
@alexpetros
Use fetch method definition
054b8dd
@alexpetros alexpetros force-pushed the put-patch-delete-forms branch from f4fc873 to 054b8dd Compare August 3, 2025 00:38
@alexpetros
Copy link
Author

alexpetros commented Aug 3, 2025 •
edited
Loading

Thanks for the review Dom! I've made all the changes you suggested, including updating the commandfor example. I am more than happy to add more RESTful resource management examples that demonstrate the utility of these methods as well.

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.

Yes! I believe these two PRs satisfy the feature.

There are changes to the navigation machinery here, but they are thankfully quite small: they replace the assumption that the inclusion of a "request resource" (f.k.a. "POST resource") implies a POST request. In place of that assumption, navigations make use of the session history object's new "method" attribute.

  • line 60630 - uses the form "method" attribute to call the navigation with that method
  • line 100230 - adds the "method" field to the session history object (defaulting to GET)
  • line 101278 - adds "method" as a parameter for navigations
  • line 101626 - sets the session history object's method to the one that the navigation was called with
  • line 103617 - sets the fetch's method to the one in the session history object

(line numbers are as of this writing, it's hard to make permalinks on a file this large)

All the machinery for making PUT, PATCH, and DELETE requests already exists in the fetch spec, including CORS preflight requests. The fetch PR simply allows requests with mode=navigation to make CORS requests, as would be required by cross-origin PUT, PATCH, and DELETE requests. While this introduces a new failure mode for navigations—not succeeding CORS—the possibility that a navigation's fetch might not succeed is adequately handled by both specifications already (in implementation, it might be worth adding a new error page, but I don't think this is covered in the spec itself, nor is it strictly necessary).

This design also minimizes the security surface of the change by not making the browser capable of any new network requests. PUT, PATCH, and DELETE methods are already supported by fetch()—this just brings those capabilities to HTML.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@domfarolino domfarolino domfarolino left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
addition/proposal New features or enhancements topic: forms
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@alexpetros @AramZS @Fake-User @domfarolino
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy