Re: Restoring PUT and DELETE

As long as we focus on what it takes to implement PUT/DELETE (per RFC2616)
in HTML, I think we'll have done a good job.

I don't see how we can give guidance to *servers* on how to handle
PUT/DELETE requests from browsers using HTML.FORM.

Just as we cannot currently prevent browsers using scripting XHR requests
for PUT/DELETE from sending "improper" requests to WebDAV servers, I do not
think we'll be able to prevent browsers from sending "improper" request to
WebDAV servers via HTML.FORMs.

I think it *is* important to make sure browsers are prepared for
server responses (204, 3xx, etc.) and act responsibly. We have the same
challenge whether the request is initiated via XHR or HTML.FORM.

IOW, I do not think implementing PUT/DELETE via HTML.FORM adds any
additional risk to WebDAV or any other servers. This risk already exists
due to browser support for XHR (including, AFIACT, the 3xx "risks").

 mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me




On Fri, Dec 2, 2011 at 09:06, Julian Reschke <julian.reschke@gmx.de> wrote:

> On 2011-12-02 14:54, Cameron Heavon-Jones wrote:
>
>> ...
>>
>>  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.
>>>
>>>
>> I agree with Mike - i don't think the response is of ultimate concern for
>> the form. the form's role should be to capture and create the desired http
>> request.
>>
>
> The response is a concern for how the browser processes the response, so I
> don't think we can ignore that here.
>
>
>  there is no need for webdav server or any other server to send a payload
>> with its response, this is up to the server application to define.
>>
>
> That doesn't parse for me. A WebDAV server *is* a server application.
>
>  ...
>>
>>  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.
>>>
>>>
>> I also don't know what's wrong with multipart. Why can't we write servers
>> which consume multipart media?
>>
>
> Many current server implementations of "PUT" treat the payload as what
> should be stored, and do not unwrap it. Why would they?
>
> The way to PUT binaries is to send them as-is.
>
> What problem do we solve by using multipart?
>
>
>  ...
>>>>        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
>>>
>>>
>> Yes i agree the redirection handling should be uniform across browsers
>> but the impact is not limited to PUT and DELETE or their inclusion in forms.
>>
>
> No, it also affects XHR, where all except UAs expect IE and Chrome (>=17)
> are broken. Apparently this is hard to fix, so it would be great if we
> could avoid *new* code to rely on something that is broken.
>
> Best regards, Julian
>
>
>