- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Fri, 2 Dec 2011 14:33:53 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: mike amundsen <mamund@yahoo.com>, Yehuda Katz <wycats@gmail.com>, HTML WG <public-html@w3.org>
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