- From: mike amundsen <mamund@yahoo.com>
- Date: Wed, 30 Nov 2011 17:27:13 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Yehuda Katz <wycats@gmail.com>, HTML WG <public-html@w3.org>
- Message-ID: <CAPW_8m7RUq-vRvd_ae2Px0-13EW7HipabyR6GOrHzsrt0AUcUA@mail.gmail.com>
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/<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 Wednesday, 30 November 2011 22:27:43 UTC