Re: Restoring PUT and DELETE

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

Received on Friday, 2 December 2011 14:06:43 UTC