Re: PUT and DELETE methods in form@method

why can't a 201 just include some body content like a 200? This would allow for any response status to include html content for rendering the response to the user. The response content may not be available through any other uri of method but it seems like thats the way it should work.

cam

On 30/03/2011, at 1:47 PM, T.J. Crowder wrote:

> Hi,
> 
> On 30 March 2011 13:04, Dominik Tomaszuk <ddooss@wp.pl> wrote:
> On 30.03.2011 00:02, Mounir Lamouri wrote:
> You can found here the reasons of the removal:
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671
> Well, I've seen it. But I do not find there any real reason to removal PUT and DELETE (and HEAD?) from spec. The reason that PUT and DELETE have no real use case for me is not true, because there are millions of RESTful impelemntations that use PUT and DELETE (of course, use of strange solutions because browsers do not support them).
> 
> But are those RESTful implementations using PUT and DELETE *with HTML forms*? That's the crux of the matter as far as I can tell in the bug report. With a non-ajax HTML form, the form submission results in the response page being shown in the browser. Servers reply to these HTTP methods with little or no response body showing the end user what happened (as the status -- 201, etc. -- is sufficient). That leaves the question of what the browser should show the user and whether that should be mandated by the HTML specification. (Clearly what the *server* replies with is out of scope for HTML; it's in the  HTTP domain.) The form is either being submitted with no target, which would mean the user is left with a blank page or the single word "successful" or something; or it's submitted with a target, and that target window will be blank or have the single word "successful" or something.
> 
> In contrast, when you use PUT or DELETE with XHR, your code is interpreting the result, perhaps removing an item from a displayed list, etc.
> 
> In other words, the actions make plenty of good sense for HTTP, but what should they mean in an HTML forms context?
> 
> It may well be that there's a good thing that they can and should mean, that browsers should do. If you have a suggestion in mind, lay it out in detail for the group and I expect they'll consider it.
> 
> FWIW,
> --
> T.J. Crowder
> Independent Software Engineer
> tj / crowder software / com
> www / crowder software / com