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

On 02/04/2011, at 11:58 AM, mike amundsen wrote:

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

Slow progress but progress none the less :)


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

I would hesitate at making references to WebDAV. This is an extension of HTTP and as such introduces additional functionality which, IMO, is not appropriate for the top-level specification.


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


While i have no problem with JSON as an enctype, i would hesitate at adding it specifically because it leads on to supporting XML. 

I honestly have no idea how form data could be represented as XML, would this be it's own schema or would authors be able to specify one? 

I think the current enctypes are more than adequate at representing the form elements as they have been specifically designed for such task.


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

Yes, these attributes are definitely required. As additionals there should be no inconsistencies in introducing them.


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

I think PUT and DELETE should follow POST in regards to the action URI. Personally i'm not too keen on GETs producing URIs and would prefer there to be at least the option of embedding the form data. Maybe this could be specified as a new encType - "text/uri" or somelike...

why would the need for a template arise? to PUT to a resource implies the resource already exists, it can be used as a creational operation as described in the example but that would seem to be leeking server-side implementation details (the id) into the client and introduce coupling.


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

I suggested using the Accept header as this is how content negotiation works everywhere... why reinvent what is already there? Why should it be ignored just because the request is from a form submission? 

I think the focus on existing servers and services is unhelpful for the specification of new features. Of course they won't be supported retrospectively but it's about allowing new services to function fully.

Current implementations of PUT and DELETE definitely won't be returning content but then these services currently aren't designed for human interaction anyway. They will require forms to be created and they will require the HTML results of processing those forms to be created too.


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

I would suggest that ALL http responses MUST be rendered by the user agent. It should make no matter what the response status is for a user to see the result of their request.


>> 
>>> ...
>> 
>> Best regards, Julian
>> 
> 
> I'll work up an updated doc reflecting your feedback and post it later today.
> 
> MCA
> 


Apologies for the brevity of the responses...please ask me to clarify anything which is under specified. I will continue looking at this and try to provide some more feedback.

Thanks,
Cam

Received on Saturday, 2 April 2011 15:33:32 UTC