Re: Restoring PUT and DELETE

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 2:27 PM, mike amundsen <mamund@yahoo.com> wrote:

> Julian:
>
> all good points.
>
> Yehuda: any thoughts from you that I should include?
>

I should have time to review and provide feedback today. :)


>
> i'll clean this up and re-post to the list w/ some follow up remarks so we
> can continue the discussion.
>
> thanks.
>
> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
>
>
>
>
> 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.
>>
>>  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.
>>
>>  ...
>>>
>>> <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.
>>
>>
>>> 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.
>>
>>  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.
>>
>>  How do WebDAV servers commonly respond to PUT/DELETE? (Mike Amundsen)
>>>
>>
>> PUT -> 200 or 201 (for new resources)
>>
>> DELETE -> 200 or 204.
>>
>>  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.
>>
>>  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.
>>
>>  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.
>>
>>  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.
>>
>>  ...
>>>
>>
>> Best regards, Julian
>>
>
>

Received on Thursday, 1 December 2011 21:07:31 UTC