Re: Restoring PUT and DELETE

Julian:

all good points.

Yehuda: any thoughts from you that I should include?

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 Wednesday, 30 November 2011 22:27:43 UTC