Re: Restoring PUT and DELETE

Yehuda Katz
(ph) 718.877.1325


On Thu, Dec 1, 2011 at 1:44 PM, mike amundsen <mamund@yahoo.com> wrote:

> i updated the web page to link to Cameron's browser matrix and made some
> edits based on Julian's feedback.
>
> see additional comments inline.
>
> BTW - not sure if it makes sense, but maybe this should be handled via an
> I-D since that will generate diffs, etc.
>
> Mike
>
> On Wed, Nov 30, 2011 at 17:16, Julian Reschke <julian.reschke@gmx.de>wrote:
>
>> On 2011-11-30 22:58, mike amundsen wrote:
>>
>>> Julian:
>>>
>>> I while back, I posted a page that, I think, covers your questions:
>>> http://amundsen.com/examples/**put-delete-forms/<http://amundsen.com/examples/put-delete-forms/>
>>> ...
>>>
>>
>> Some of them; thanks for what you have so far. This is exactly what needs
>> to happen; I just don't think we're done yet. Also, I encourage people to
>> read all of this; it's *not* a matter of just "restoring" PUT and DELETE.
>>
>> Here are a few comments:
>>
>>  1.3.
>>> A Simple HTML Example
>>>
>>> <form action="http://example.org/**user/12 <http://example.org/user/12>"”
>>> method=”put” if-match="*">
>>>  <input name="user-name" type="text" value="" />
>>>  <input name="hat-size" type="text" value="" />
>>>  <input type="submit" />
>>> </form>
>>>
>>> Filling the “user-name” and “hat-size” inputs with “mike” and “small”
>>> respectively, will result in the following HTTP request:
>>>
>>> PUT /user/123 HTTP/1.1
>>> Host: example.org
>>> Content-Type: application/x-www-form-**urlencoded
>>> If-Match: "*"
>>> ...
>>> user-name=mike&hat-size=small
>>>
>>
>> The example should include the response, and information what the UA is
>> supposed to do with it.
>>
> MCA: well, servers could have a number of possible responses. I added a
> section on that "Responses" If that's not what you had in mind, let me know.
>
>
>>  3.
>>> Sample Usage Scenarios
>>>
>>> Below are example usage scenarios for PUT and DELETE w/ HTML Forms.
>>> 3.1.
>>> Creating a New Resource
>>>
>>> PUT can be used to create a new resource.
>>>
>>> *** REQUEST
>>> GET /users/;create HTTP/1.1
>>> Host: www.example.org
>>> ...
>>>
>>> *** RESPONSE
>>> 200 OK HTTP/1.1
>>>
>>
>> That should be 201.
>>
> MCA: well this example shows one response to get the HTML.FORM
> representation (GET /users/;create) and another request to actually create
> a new resource (PUT /users/123). so the first RES/REQ returns 200, the
> second should return 201.
>
>>
>>  ...
>>>
>>> <html>
>>> ...
>>> <form action=”http://www.example.**org/users/123<http://www.example.org/users/123>”
>>> method=”put” if-none-match=”*”>
>>>  <input name=”user-name” value=”” />
>>>  <input name=”hat-size” value=”” />
>>>  <input type=”submit” />
>>> </form>
>>> ...
>>> </html>
>>>
>>> *** REQUEST
>>> PUT /users/123 HTTP/1.1
>>> Host: www.example.org
>>> If-None-Match: "*"
>>> Content-Type: application/x-www-form-**urlencoded
>>> Content-Length: nnn
>>>
>>> user-name=mike&hat-size=small
>>>
>>> *** RESPONSE
>>> 200 OK HTTP/1.1
>>> ...
>>> <html>
>>> ...
>>> <ul>
>>>  <li>user-name: mike</li>
>>>  <li>hat-size: small</li>
>>> </ul>
>>> ...
>>> <html>
>>>
>>
>> Here, the server sends a new HTML page for display. Servers currently do
>> not do that upon PUT. We need to tell what we expect from them (yes, see
>> below).
>>
>
>> This applies to the other examples as well.
>
>
> MCA: not so sure about "servers don't currently do that" i encounter
> servers that return entity bodies for 201. bigger picture here is that i
> don't think we want to get into too much detail on what the response entity
> SHOULD be when spec'ing HTML.  HTTP covers that space already. possibly we
> need better examples (plural) here, tho.
>
>
>>
>>
>>> 3.4.
>>> Binary Transfers
>>>
>>> PUT can be used to send binary data to servers.
>>>
>>> *** REQUEST
>>> GET /users/123/avatar HTTP/1.1
>>> Host: www.example.org
>>> Accept: text/html
>>> ...
>>>
>>> *** RESPONSE
>>> 200 OK HTTP/1.1
>>> ...
>>>
>>> <html>
>>> ...
>>> <form action=”http://www.example.**org/users/123<http://www.example.org/users/123>”
>>> method=”put” if-match=”*”>
>>>  <input type="file" name="imagefile" value="" />
>>>  <input type=”submit” />
>>> </form>
>>> ...
>>> </html>
>>>
>>> *** REQUEST
>>> PUT /user/123/avatar HTTP/1.1
>>> Host: example.org
>>> If-None-Match: "*"
>>> Content-Type: multipart/form-data; boundary=---------------------**
>>> ------3652875324033
>>> Content-Length: nnn
>>>
>>> -----------------------------**3652875324033
>>> Content-Disposition: form-data; name="imagefile";
>>> filename="my-avatar.jpg"
>>> Content-Type: image/jpeg
>>>
>>> ... binary data ...
>>>
>>
>> Why multipart? Typical implementations of servers that do PUT store the
>> content as is and do not process multipart.
>>
>
> MCA: why not? IOW, are you suggesting the HTML spec add a MUST NOT on the
>  use of multipart for  HTML.FORM@method="put"? if so, why?
>
>>
>>  4.
>>> Other Considerations
>>>
>>> 4.1.
>>> Handling Responses
>>>
>>> Typical responses from PUT (200/201/204) and DELETE (200/202/204) SHOULD
>>> be handled the same way these responses are handled for POST[cite].
>>>
>>> How *are* they handled by UAs? (Is this in HTML5?). (Julian Reschke)
>>>
>>
>> That's something we need to clarify.
>>
> MCA: added a link to Cameron's page. more might be needed, too.
>
>
>>
>>  How do WebDAV servers commonly respond to PUT/DELETE? (Mike Amundsen)
>>>
>>
>> PUT -> 200 or 201 (for new resources)
>> DELETE -> 200 or 204.
>>
> MCA: added these to the doc, too. thanks.
>
>>
>>  4.2.
>>> Handling Security
>>>
>>> Security constraints for PUT/DELETE via FORMS SHOULD be handled the same
>>> as using PUT/DELETE via XHR.
>>>
>>
>> So PUT and DELETE cross-origin only work with CORS.
>>
> MCA: yes, for current Web browsers i think this is the way it will be. I,
> for one, do not want to try to convince browser vendors to treat PUT/DELETE
> requests generated from markup differently than requests generated from
> script
>
>>
>>  4.4.
>>> Optional Added FORM Content-Types
>>>
>>> Currently, HTML FORMS support three content-types for sending request
>>> entities[cite]:
>>>
>>>    application/x-www-form-**urlencoded
>>>    multipart/form-data
>>>    text/plain
>>>
>>> It is possible that additional content-types could be supported for
>>> FORMS including JSON[cite] and XML[cite]. While this is not required in
>>> order to add support for PUT in HTML FORMS, there are a number of scenarios
>>> where this will be desireable. It is assumed that any additional
>>> content-types would be supported for FORMS where the "method" atttribute is
>>> set to POST or PUT.
>>>
>>
>> That'll break assumptions about CSRF defences, I believe.
>>
> MCA: good point. i'm not a fan of this option and would be fine if it was
> not included.
>

For what it's worth, those defenses are actually invalid. Rails (a
framework I work on) and other frameworks recently overhauled our CSRF
defenses because there were ways to circumvent the normal assumptions about
CSRF defenses with existing browsers (through the use of Flash). You can
see our security notice at
http://weblog.rubyonrails.org/2011/2/8/csrf-protection-bypass-in-ruby-on-rails
.

More details are available on the webappsec list:
http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html
.


>
>>  4.5.
>>> Optional Support for Prefer Header
>>>
>>> It is possible that HTML FORMS could support the Prefer Header[Prefer]
>>> as a way to communicate to the server the agent's preference for a
>>> response. This would allow agent's to indicate they wish a body returned
>>> for responses where a body MAY not always be returned by servers (201/202).
>>>
>>
>> Yes. We should work on that Internet Draft.
>>
> MCA: true.
>
>>
>>  4.6.
>>> Support for Atom-Style PUT/DELETE
>>>
>>> The current proposal relies on added attributes in the FORM element (see
>>> above). An alternative approach is to adopt the way AtomPub[AtomPub]
>>> handles PUT/DELETE; only support it in cases where the current response
>>> representation is the actual resource to PUT/DELETE.
>>>
>>
>> That's also WebDAV's point of view, I believe.
>>
> MCA: yes, i think this is the right way to go; esp. when you take into
> account ETag header dealings.
>
>>
>>  ...
>>>
>>
>> Best regards, Julian
>>
>
>

Received on Thursday, 1 December 2011 21:50:08 UTC