[Bug 10671] consider removing support for PUT and DELETE as form methods

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671

Marcus <claydragon@web.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |claydragon@web.de

--- Comment #11 from Marcus <claydragon@web.de> 2011-04-05 11:26:09 UTC ---
Quickly writing this off the top of my head...

I've always thought about it like this with the methods in HTML forms - quick
recap:

POST: form data is collected (as defined by HTML), encoded in the given
"enctype" and submitted as the request body to the URL in the "action"
attribute.

GET: this method, as defined by HTTP, must not have a request body (I think
servers are advised to even discard any body, if I remember correctly), so the
form data will be submitted as the query string of the URL given in the
"action" attribute. The encoding format "defaults" to
"application/x-www-form-urlencoded".

So basically _GET_ is the special case, because the natural way of sending data
to a server would be as the request body. Which basically means for the methods
PUT and DELETE:

PUT: virtually the same as POST, from the form's point of view.

DELETE: just like GET, this method must not have a request body. Should be
handled the same way as GET (lump the form data into the query string).

Here are my brainstormed ideas for enriching HTML forms:

Since HTTP defines a couple of standard methods, but adding custom methods is
absolutely allowed, I think HTML forms should not restrict the methods in the
"method" attribute. Unknown methods (not in the original HTTP specification)
should be handled the same way as POST or PUT. This would eg. allow the PATCH
method defined in RFC 5789 to basically work (but which probably needs a new
"enctype" anyway).

We could also add an attribute that defines "where" the form data is sent,
something like

<form where="query-string" method="FOO"> (GET/DELETE methods imply
"query-string")
<form where="body" method="BAR"> (POST/PUT methods imply "body")

and maybe even

<form where="header" method="BAR"> (to send form data as additional HTTP
headers instead; haven't thought about security implications with this, just an
idea)

This would allow for custom methods to be sent via query string as well (we
could also call the attribute "via", "position" or something).

I also consider DELETE a special case, that could be handled in an alternate
way. Since a user-triggered GET request in HTML is also made by clicking on a
hyperlink (a functionality which can be emulated using a GET HTML form), and
DELETE requests will probably mostly point to a specific resource where it
makes no sense to add a query string (eg. http://example.com/users/42), maybe
we could extend button/input elements:

<button type="delete" url="http://example.com/users/42">Delete User
Douglas</button>

Such an element needs not be contained inside a form element and just sends the
DELETE request to the specified URL. Clients could by default show a
confirmation dialog before actually submitting a DELETE request.

Other things I've thought about are how it could be done to eg. send a file
(let's say an "image/png") to a URL with its correct MIME type using forms in
HTML (without wrapping it inside a "multipart/form-data" body), which might be
interesting for PUT. Maybe an attribute like "only":

<form method="PUT" action="..." enctype="image/png" only="foobar">
<input type="file" name="foobar" accept="image/png" />
<button type="submit">Upload</button>
</form>

"enctype"/"accept" could be omitted to allow arbitrarily formatted data to be
sent (and let the client make his best efforts to guess the MIME type of the
uploaded file).

With this we could start to build interfaces in HTML forms for easy interaction
with RESTful webservices.

One last thing about the server's response: replying with a "200 OK" status is
perfectly valid for PUT and DELETE requests. BTW, last time I checked, Firefox
honors the "204 No Content" status as defined by HTTP, by sending the form and
not resetting the document view. I know of the "onsubmit" event triggered by
browsers to use with JavaScript, but is there something like an
"onsubmitcomplete" event as well? Would be interesting to know how other
browsers handle this or similar response statuses. Browsers should definitely
somehow notify the user on "204 No Content" by displaying an asynchronous
notification box.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 5 April 2011 11:26:13 UTC