Html: HTML forms do not support the PUT, PATCH and DELETE methods

[ericandrewlewis]

Hi! This is my first issue in this repository, I'm sorry if I'm opening this discussion in the wrong place. I searched the mailing list archives and issues for this topic but couldn't find a relevant discussion.

The spec says that the <form> method attribute assumes one of three values: get, post, and dialog.

Can we add support for the put, patch, and delete methods for this attribute?

[annevk]

Probably not as that would complicate the processing model for <form> quite significantly. In particular, the same origin policy exceptions <form> has today do not allow for these methods. Either we have to forbid them in cross-origin requests or require CORS somehow. Both of those restrictions would be a first for navigations and rather risky.

[js-choi]

As a developer, I would love this feature. Those of us who are still interested in this sort of feature may want to make a new thread in the WICG Discourse forum and post their use cases there.

[annevk]

Just know it's been attempted several times in the past and implementers have rejected it.

[annevk]

(It even used to be part of Web Forms 2.0.)

[js-choi]

Indeed—if I recall, Hickson said long ago that there weren’t clear use cases for them…or was that for JSON form data? Well, either way, that’s why any chance of this happening would require assembling compelling use cases for them and marshaling both coordinated community support and a reasonable specification for the vendors. A tall order, but less likely things have happened…

[annevk]

I am pretty sure that the main reason implementers have rejected it is complexity.

[ericandrewlewis]

@annevk thanks for the context, I suspected this would have came up previously. Where would discussion from the previous attempts have taken place? They would be interesting to read.

[annevk]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671 seems to have a lot of it, though not as much the implementer angle.

[annevk]

As an update, https://github.com/whatwg/html/issues/3577#issuecomment-374109222 still applies. We cannot bypass the same-origin policy and enforcing CORS is theoretically possible, but would require integration of that to some extent with navigation, which is completely new ground. Maybe if something like https://wicg.github.io/cors-rfc1918/ motivated adding such complexity to navigation this would become more feasible. But until that happens this isn't worth the significant cost unfortunately.

[lpd-au]

In particular, the same origin policy exceptions <form> has today do not allow for these methods.

Thanks for your comments @annevk. Can you point me in the direction of where these exceptions are specified? Between GET and POST, they seem to have every property of PUT and DELETE covered; request body, idempotency, navigation, etc... does it raise a fresh security concern or is this a legacy issue where the specification that defines the exceptions repeats only the HTML 4 form methods by name?

Either we have to forbid them in cross-origin requests or require CORS somehow. Both of those restrictions would be a first for navigations and rather risky.

To me, implementing PUT and DELETE with a same-origin policy seems like a sensible minimum viable product, which would at least allow web developers to create html clients for their own REST services. Implementer interest permitting, this could later be extended with CORS support for both PUT and DELETE methods (opt-out) and GET and POST methods (opt-in). Could you also please elaborate on why you previously considered a same-origin policy for PUT and DELETE forms to be 'risky', and whether you still believe this to be the case? How does this compare to, for example:

1. POSTing to a cross-origin HTTPS resource with an invalid TLS certificate configuration, or
2. GETting a resource when the network is disconnected/offline, or
3. POSTing from a HTTPS form to a HTTP resource?

[annevk]

HTML defines part of it and so does https://fetch.spec.whatwg.org/. And yes, what HTML forms can do are basically the enshrined exception.

A same-origin mode would similarly be risky (and unclear) as navigation does not have that primitive. So you'd have to define what happens if you get a cross-origin redirect and how that would be handled and such. And come to think of it, there's also a couple POST-specific code paths that would have to be generalized somehow.

[lpd-au]

HTML defines part of it and so does https://fetch.spec.whatwg.org/. And yes, what HTML forms can do are basically the enshrined exception.

That is to say, the exception could be extended if the specification editors such as yourself thought it prudent? There is no immovable W3C charter issue, for example, or fresh security concern that does not apply to the existing methods?

A same-origin mode would similarly be risky (and unclear) as navigation does not have that primitive. So you'd have to define what happens if you get a cross-origin redirect and how that would be handled and such. And come to think of it, there's also a couple POST-specific code paths that would have to be generalized somehow.

I'm afraid I still don't understand. Perhaps you could define what you mean by risky, or elaborate what some of the risks are? Is there an inherent problem or insurmountable issue with having to define how redirects are handled, or generalising code previously implemented to handle POST? Is this not still significantly less complex than CORS support?

[annevk]

No, the same-origin policy cannot be extended further as that would put servers at risk.

The risk is that there are a lot of corner cases to handle and navigation is one of the more broken concepts in the HTML Standard. Same-origin is probably less work than CORS, but it's still a lot of work.

[tkawa]

To help with the discussion, there are two drafts. These are highly complete specifications made as a result of past reviews.

• W3C HTML Form HTTP Extensions
• Supporting PUT and DELETE with HTML FORMS

IMHO, the latter has considerably less complexity.

[annevk]

Neither of those is close to complete as neither goes into the detailed changes needed to HTML's navigate algorithm.