- From: mike amundsen <mamund@yahoo.com>
- Date: Thu, 1 Dec 2011 16:17:52 -0500
- To: Yehuda Katz <wycats@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTML WG <public-html@w3.org>
- Message-ID: <CAPW_8m6NxJN5DiCJXTnNSbP5A2eQcNA=aKoBgGUGYj=wyuAR-w@mail.gmail.com>
i'm posting an update to the web page now and will ping the list when it's done. mca http://amundsen.com/blog/ http://twitter.com@mamund http://mamund.com/foaf.rdf#me On Thu, Dec 1, 2011 at 16:06, Yehuda Katz <wycats@gmail.com> wrote: > > Yehuda Katz > (ph) 718.877.1325 > > > On Wed, Nov 30, 2011 at 2:27 PM, mike amundsen <mamund@yahoo.com> wrote: > >> Julian: >> >> all good points. >> >> Yehuda: any thoughts from you that I should include? >> > > I should have time to review and provide feedback today. :) > > >> >> 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/<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 <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<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<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 Thursday, 1 December 2011 21:18:29 UTC