Re: Restoring PUT and DELETE

On 02/12/2011, at 2:06 PM, Julian Reschke 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.

yes, i don't suggest to ignore the problem more questioning whether they are separate issues.

> 
>> 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.

yes but not every server implementing PUT is webdav.

> 
>> ...
>>> 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?

i think the usage of PUT should be a bit more flexible than binary representations - the semantics are on uploading a representation, not a binary copy.


> 
>>>> ...
>>>>        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
> 
> 

ok, but that is still a different problem and while related i don't think it should hold back specifying how forms can work.

thanks,
cam

Received on Friday, 2 December 2011 14:34:35 UTC