- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Fri, 2 Dec 2011 13:54:45 +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 01/12/2011, at 9:57 PM, Julian Reschke wrote: > On 2011-12-01 22:44, mike amundsen wrote: >> ... >> >> <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. > 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. 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. >> 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. > I also don't know what's wrong with multipart. Why can't we write servers which consume multipart media? >> ... >> 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. thanks, cam
Received on Friday, 2 December 2011 13:55:24 UTC