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

Re: PUT and DELETE methods in 200 code

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 04 Apr 2011 21:43:19 +0200
Message-ID: <4D9A1F57.8090700@gmx.de>
To: mike amundsen <mamund@yahoo.com>
CC: Cameron Heavon-Jones <cmhjones@gmail.com>, public-html@w3.org
On 04.04.2011 20:37, mike amundsen wrote:
> <snip>
>> ...but it *does* depend on the semantics of
>> the method.
> </snip>
> I'm sure this is just me being a bit dense (losing details in the
> emails, etc.), but 'm not following that last part.
> "it" (the response code?) depends on the semantics of (PUT) the method? or
> "it" (what the server returns?) depends on the semantics of (PUT) the method?

The latter.

> ...
> Since PUT supports both create and update, I assume you mean to assert
> that servers should "know" whether this is a create or update and that
> the response would be altered accordingly (e.g. PUT(create) MAY return
> a 201, but a PUT(update) SHOULD NOT return a 201, etc.).  Do I have
> that right? If that's the case, servers can make that determination on


> their own; the same way it is done today (w/o FORMS).  I don't see how
> introducing an HTML FORM as the initiator of the request changes that
> (e.g. I don't know what _new_ thing HTML FORM-generated PUT introduces
> that might 'confuse' servers as to how to handle the request and
> generate the 'proper' response).

No; what I wanted to say is that the originator affects the kind of 
payload to return, not the status code.

> In addition, servers are not REQUIRED to enforce the inclusion of the
> If-none-match (for PUT(create) or if-match (for PUT(update)) headers
> for PUT. Therefore, any attempt to try to "infer" anything from these
> headers will fail in cases where the headers do not appear.


Best regards, Julian
Received on Monday, 4 April 2011 19:44:04 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:11 UTC