- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 02 Dec 2011 15:29:38 +0100
- To: mike amundsen <mamund@yahoo.com>
- CC: Cameron Heavon-Jones <cmhjones@gmail.com>, Yehuda Katz <wycats@gmail.com>, HTML WG <public-html@w3.org>
On 2011-12-02 15:16, mike amundsen wrote: > 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 believe that's only 50% of the story. > I don't see how we can give guidance to *servers* on how to handle > PUT/DELETE requests from browsers using HTML.FORM. No, we need to define things so that servers can continue to do what they to today *and* support these requests from forms. This may mean that the UAs need to deal with responses in a way they haven't so far, for instance by dealing with a DELETE->204. Or it could mean that we have to give servers the information they need so that they can send UAs a different response body. > 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. For XHR this is a non-issue, as the payload of the response doesn't drive what the UA does next. It's up to the script author. For forms, it'll be up to the UA itself, so it needs to be considered. > 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. How's that a problem with XHR? > 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"). Yes, but it would be good not to make the problem bigger as it already is. Best regards, Julian
Received on Friday, 2 December 2011 14:30:18 UTC