Re: Restoring PUT and DELETE

On 2011-12-01 22:44, mike amundsen wrote:
> i updated the web page to link to Cameron's browser matrix and made some
> edits based on Julian's feedback.
>
> see additional comments inline.
>
> BTW - not sure if it makes sense, but maybe this should be handled via
> an I-D since that will generate diffs, etc.
>
> Mike
>
> On Wed, Nov 30, 2011 at 17:16, Julian Reschke <julian.reschke@gmx.de
> <mailto: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 <http://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.
>
> MCA: well, servers could have a number of possible responses. I added a
> section on that "Responses" If that's not what you had in mind, let me know.

s/the/a/ - I think the example should show a plausible response.

>         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 <http://www.example.org>
>         ...
>
>         *** RESPONSE
>         200 OK HTTP/1.1
>
>
>     That should be 201.
>
> MCA: well this example shows one response to get the HTML.FORM
> representation (GET /users/;create) and another request to actually
> create a new resource (PUT /users/123). so the first RES/REQ returns
> 200, the second should return 201.

Yes, I meant the latter.

>         ...
>
>         <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 <http://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.
>
>
> MCA: not so sure about "servers don't currently do that" i encounter
> servers that return entity bodies for 201. bigger picture here is that i
> don't think we want to get into too much detail on what the response
> entity SHOULD be when spec'ing HTML.  HTTP covers that space already.
> possibly we need better examples (plural) here, tho.

WebDAV servers I'm aware of send empty responses or short notes like 
"resource stored". I've never seen a WebDAV server return the written 
entity (why would it?), let alone a full HTML page describing the resource.

Now of course doing so is legal, but the server really needs to 
understand the use case; thus we need "Prefer:" or something like that.

If we don't specify this, people will do U-A sniffing. Ouch.

>         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 <http://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 <http://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.
>
>
> MCA: why not? IOW, are you suggesting the HTML spec add a MUST NOT on
> the  use of multipart for  HTML.FORM@method="put"? if so, why?

The best way to PUT binary data is, well, to send it in its native format.

Forcing servers to unwrap multipart here means that you can't either 
store multipart/form-data verbatim anymore, or that you need to special 
case the client again.

> ...
>         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.
>
> MCA: yes, for current Web browsers i think this is the way it will be.
> I, for one, do not want to try to convince browser vendors to treat
> PUT/DELETE requests generated from markup differently than requests
> generated from script

Absolutely. Everything else would break security assumptions.

> ...
>         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.
>
> MCA: yes, i think this is the right way to go; esp. when you take into
> account ETag header dealings.
> ...

One thing I forgot earlier, and which was the reason why I actually 
wanted PUT and DELETE temporarily (!) on hold is redirect handling.

The experimental Firefox implementation was copying the redirect 
handling for POST (with respect to method rewriting), and it would have 
been bad to let this get into the deployed platform.

So it would be good to clarify that PUT and DELETE, when being 
redirected by 301/302 should *not* be rewritten to GET.

Best regards, Julian

Received on Thursday, 1 December 2011 21:59:05 UTC