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

Julian:

My comments inline....

On Sat, Apr 2, 2011 at 05:50, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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.

I agree. we've gone w/o PUT/DELETE in HTML for more than a decade,
working this through slowly doesn't add any hardship<g>.

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

sounds ok.

>
>> 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?
PUT certainly doesn't *require* it, but if the WG wants to use PUT as
a "stalking horse" to expand the range of enc-types supported by HTML,
that's fine w/ me. If we go down that road, i suspect XML should also
be added as an enc-type, too.

>
>> 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.
I'll add an example using multipart, too.

>
>> 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).
Yep. this is, IMO, the key functionality missing in HTML today that
(without it) makes PUT/DELETE unworkable for most situations. There
are some alternatives such as
- never sending them (will likely break w/ many existing servers,
teaches bad habits, can result in the lost update problem)
- always send "*" under the covers (there's a problem w/ PUT since
PUT(create) expects "if-none-match" & PUT(update) expects "if-match")
- adopt a non-protocol-specific model
(method="get|post|update|create|delete" concurrency="w/aqswde")
- there may be others

>
>> 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?
Templates are an option (although the I-D is still in flux there,
right?). I suspect this is primarily interesting in the PUT(create)
case as PUT(update) and DELETE can easily get complete URIs. HTML
adopted the pattern of encoding INPUT values into the URI for GET and
into the body for POST. Seems awkward to "mix" these two behaviors for
PUT/DELETE, but I'm open to exploring support for URI Templates in
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>
>
> 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>.
Yeah, Snell's notion seems closer to what might be desireable. Of
course, having agent add a new (optional) header will not likely
improve the results from any existing servers.

>
> (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).
Yep, good catch.

>
>> ...
>
>> 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?).
Excellent question<g>. I have _assumed_ since servers are free to emit
201/202/204 for POST today that the HTML WG had no real concern for
this case. It's not clear to me why adding PUT/DELETE to the list of
supported methods alters the importance of handling these types of
responses, but I'm open to hearing more about it.

>
>> ...
>
> Best regards, Julian
>

I'll work up an updated doc reflecting your feedback and post it later today.

MCA

Received on Saturday, 2 April 2011 11:00:52 UTC