W3C home > Mailing lists > Public > public-html-comments@w3.org > December 2011

Re: Follow-up about PUT and DELETE in form methods

From: mike amundsen <mamund@yahoo.com>
Date: Tue, 13 Dec 2011 10:09:01 -0500
Message-ID: <CAPW_8m6W61aussxcFtK44Jvx9TqGr5nLdu5MpvT3ezjMo9L8zA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mirko Gustony <mirko.gustony@gmail.com>, Cameron Heavon-Jones <cmhjones@gmail.com>, thibault <thibault@miximum.fr>, public-html-comments@w3.org
Based on repeated comments about what this issue of what the browser
user-agent *expects* as a return for PUT/DELETE, I wonder if things
would go better if the Prefer header proposal was included in all


On Tue, Dec 13, 2011 at 10:04, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2011-12-13 15:23, Mirko Gustony wrote:
>> Hello,
>> excuse me but,
>> 2011/12/13 Julian Reschke<julian.reschke@gmx.de>:
>>>> I think that is quite definitely Out Of Scope. If there needs to be
>>>> different content for the same format this should be a different URI.
>>> I disagree. If you need separate URIs to make this work, something is
>>> wrong.
>> from my reading of [1] (and several other sources on that) Cameron
>> seems to be right. Different content (not different representation)
>> means different document and therefor different URI.
> We're talking about a single resource (thus one URI), that gets a DELETE
> request.
> Different clients have different expectations on the response payload they
> get for a successful DELETE, though. Most non-HTML clients do not care about
> any additional information, so sending more than a status message is a waste
> of bits.
> Note that HTTP says:
> "A successful response SHOULD be 200 (OK) if the response includes an entity
> describing the status, 202 (Accepted) if the action has not yet been
> enacted, or 204 (No Content) if the action has been enacted but the response
> does not include an entity." --
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7>
> So you can send a "status" page, but assuming that a server always will do
> that would be incorrect because most clients will not need it.
>> I for one would welcome a solution for bringing RESTful webservices to
>> HTML forms without hacks or Javascript.
>> ...
> Yes, but please let's not replace one kind of hack with a different kind of
> hack.
> Best regards, Julian
Received on Tuesday, 13 December 2011 19:08:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC