On Wed, Nov 30, 2011 at 17:16, Julian Reschke
<julian.reschke@gmx.de> wrote:
On 2011-11-30 22:58, mike amundsen wrote:
...
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