Re: Restoring PUT and DELETE

Hi Yehuda\Mike\Juilan,

Its good to get back to this issue, hope it keeps the traction this time :)

Without going into too much detail yet, there were two points from the last discussions to be highlighted at this point.

The first is with regards to browser handling of responses. I did some thorough testing of the current state of play of browser behaviour in this area and found that browsers are on the whole up to spec with their behaviour and that the default for content responses is to render whatever payload is returned. I have a matrix of these responses which can be added to any docs [attached].

While performing the browser tests however, i started to doubt the necessity of such tests - perhaps this is a more methodological question, but is the html specification the place for defining http behaviour? 

The other issue is that specifications for PUT and DELETE are not too held back with conformance for current server implementations. As new functionality to html and hence requiring to be explicitly added by authors there should not be any backward compatibility to break.

MIke, look forward to the updated docs.

Thanks,
Cameron Jones




On 30/11/2011, at 10:27 PM, mike amundsen wrote:

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

Attachments

Received on Thursday, 1 December 2011 11:04:11 UTC