Re: [Fwd: Re: PUT and DELETE methods in 200 code]

On 02.04.2011 02:50, mike amundsen wrote:
> Cross-posting to related groups:
>
> I've posted a document[1] that shows one way in which HTML FORMS can
> support PUT/DELETE w/o the need for plug-ins or scripting. It's a
> quick draft but I think it covers the basics.
>
> If this is not in the desired format let me know.
>
>
> [1] http://amundsen.com/examples/put-delete-forms/
> ...

Mike,

thanks for getting this started.

I think it's essential to think this through completely, not to rush it.

In the meantime I recalled the main reason why I got nervous about what 
the FF4 beta implemented; it adopted the broken XHR behavior for 
following redirects (rewriting the request method to GET), and it also 
had the URI encoding for one of the methods wrong.

Now looking at your proposal:

> Summary
>
> A proposal for supporting PUT and DELETE in HTML5 Forms.
> Goals
>
> Support for PUT/DELETE should be:
>
>     as complete as possible (per HTTP[cite] spec)
>     as seamless as possible (per current Browser behaviors)
>     easy to use via HTML (for both servers to emit and browser to process)
>     not introduce any new security problems
>     not veer substantially from support for PUT/DELETE via XHR

Personally I'd add "should integrate well with servers which already 
support PUT and DELETE, such as WebDAV servers"

> Assumptions
>
> This proposal assumes:
>
>     Any controls that are currently valid for FORMs with the method=”post” are also valid for FORMs with the method=”put.”
>     Any enc-type values that are currently valid for FORMs with the method=”post” are also valid for FORMs with the method=”put.”
>     All controls and enc-type values are ignored for FORMs with the method=”delete.”

Will we need additional enc-types? Maybe something for JSON?

> A Simple HTML Example
>
> <form action=”http://example.org/user/123” 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

It would be good to have an example that uses non-ASCII characters.

> Added Attributes for the FORM element
>
> The following OPTIONAL attributes SHOULD be supported for the FORM element. Valid values for these new attributes MUST be the same as those outlined in the HTTP spec[cite].
> If-Match
> ...

That might be hard to swallow for some (that said, I currently don't 
have a better idea *if* we want to add this kind of control).

> Below are example usage scenarios for PUT and DELETE w/ HTML Forms.
>
>     Creating a new resource
>     Editing an existing resource
>     Deleting and existing resource
>
> Creating a new resource
>
> PUT can be used to create a new resource on the server.
>
> *** REQUEST
> GET /users/;create HTTP/1.1
>
> Host: www.example.org
>
> ...
>
> *** RESPONSE
> 200 OK HTTP/1.1
>
> ...
>
> <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>

If we wanted to make the user # a variable instead of hardwiring it into 
the action attribute, we'd need to make it a URI template, right?

> *** 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>

This makes the assumption that a sender of a PUT request always is 
interested in a response body that describes the new state, which is 
most certainly *not* what most current implementations of PUT do.

Somebody mentioned that this could be handled using "Accept:", but I'm 
not entirely sure this will work well. An alternative would be using 
something like what James Snell describes in 
<http://trac.tools.ietf.org/html/draft-snell-http-prefer-03#section-5>.

(The same of course applies to DELETE)

> Updating an Existing Resource
>
> PUT can be used to update/replace an existing resource
>
> *** REQUEST
> GET /users/123 HTTP/1.1
>
> Host: www.example.org
>
> ...
>
> *** RESPONSE
> 200 OK HTTP/1.1
>
> ...
>
> <html>
>
> ...
>
> <form action=”http://www.example.org/users/123” method=”put” if-match=”q1w2e3r4t5”>
>
>  <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-Match: q1w2e3r4t5

Nit: that is not a valid ETag; it needs to be in double quotes (in the 
HTML as well, so we can also use weak etags).

> ...

> Other Considerations
>
> Below are other items for consideration.
> 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?).

> ...

Best regards, Julian

Received on Saturday, 2 April 2011 09:51:17 UTC