W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2010

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 06 Oct 2010 20:18:20 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P3aRQ-0003hI-3t@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671

Mike Amundsen <mamund@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mamund@yahoo.com

--- Comment #4 from Mike Amundsen <mamund@yahoo.com> 2010-10-06 20:18:19 UTC ---
Executing PUT and DELETE to modify resources on the origin server is
straight-forward for modern Web browsers using the XmlHttpRequest object. For
unscripted browser interactions this not so simple. Typically, devs and
frameworks end up creating work-arounds that mimic the HTTP PUT/DELETE + Etag
interaction using a "POST FORM" coupled with specialized server-side code to
sort out the special case and act as if the proper HTTP Method was used in the
request:

<!-- typical work-around to support PUT/DELETE -->
<form method="post" action="...">
  <input type="hidden" name="override_method" value="put" />
  <input type="hidden" name="hashtag" value="..." />
  ...
</form>

This pattern is required so often that several commonly-used Web
frameworks/libraries[1][2][3][4] have created a "built-in" work-around. Note
that some libraries include support for a concurrency value and some do not.

Other considerations:
- Using POST as a tunnel instead of using PUT/DELETE can lead to caching
mis-matches (e.g. POST responses are cachable[5], PUT responses are not[6],
DELETE responses are not[7])
- Using a non-idempotent method (POST) to perform an idempotent operation
(PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to
repeat this action?").
- Tunneling leads to reduced "visibility" of the application protocol over the
wire which complicates request auditing, authorization-level security, etc.
- Adding support for PUT/DELETE (along w/ inclusion of the
If-Match/If-Unmodified-Since headers) can reduce ocurrences of the "Lost
Update" concurrency problem.

[1]
http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work
[2] http://book.cakephp.org/view/183/Creating-Forms#options-type-184
[3] http://djangosnippets.org/snippets/174/
[4]
http://geekswithblogs.net/michelotti/archive/2010/01/08/implementing-a-delete-link-with-mvc-2-and-httpmethodoverride.aspx
[5] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
[6] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
[7] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7

-- 
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 Wednesday, 6 October 2010 20:18:22 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:59 UTC