Re: Restoring PUT and DELETE

i'm posting an update to the web page now and will ping the list when it's
done.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Thu, Dec 1, 2011 at 16:06, Yehuda Katz <wycats@gmail.com> wrote:

>
> 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:18:29 UTC