- From: <bugzilla@jessica.w3.org>
- Date: Sat, 10 Mar 2012 12:09:25 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671 Tom Wardrop <tom@tomwardrop.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |tom@tomwardrop.com Resolution|WONTFIX | --- Comment #21 from Tom Wardrop <tom@tomwardrop.com> 2012-03-10 12:09:20 UTC --- First, I'm surprised at the seemingly unjustified dismissal of this enhancement request. Ian, it would be helpful if you would elaborate on your current position. I'm personally in favor of adding support for the PUT and DELETE methods to the HTML specification, in fact, I'd personally like to see support for any and all HTTP request methods. HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? HTML forms play the very important role of allowing a user to send data to a HTTP server - data that's relevant to the action being performed. The action that is performed as a result of the submission is determined not by the user, but by the forms method, as defined by the designer of the form. If you we are to assume that the form designer had no control over the HTTP server, then how does the form designer allow the user of the form to DELETE or PUT a resource? It should be possible to put a HTML form in front of any HTTP server supporting GET, POST, PUT, and DELETE, and have that form be able to performing any of those actions without the need for server-side code that falls outside the HTTP specification. It's only because of server-side programming languages and programmers who have made special provisions, that we have managed to get by without PUT and DELETE support in HTML. If anyone has a static/traditional HTTP server that depends on the available HTTP methods to fulfil requests, then HTML does not allow for full interaction with the resources on that server, and I think that points to a fundamental problem with the HTML spec. With the popularity of REST, application architects want to provide a single interface for machines and humans. Applications should not have to determine who or what made the request. The HTTP method should tell the server what action should be performed, and the headers should communicate what the client expects in response. The current HTML specification does not allow for such a unified interface, at least not without work-arounds employed by application frameworks. As a human interface for HTTP, HTML has failed. It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests. If this is not reason enough for including at least the PUT and DELETE methods in the HTML specification, then it needs to be explained why. Minor implementation details like how the client should behave under certain conditions should not get in the way of determining the validity or relevance of this suggested enhancement to the HTML specification. Though I'm not entirely sure why or how PUT and DELETE would introduce any client implementation problems not already addressed by support for the POST method. It's obvious this bug report has yet to reach a resolution, I've therefore changed the status to REOPENED. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Saturday, 10 March 2012 12:09:27 UTC