Re: Restoring PUT and DELETE

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/
> ...

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"” 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” 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” 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:17:21 UTC