W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: Issue i17 (Revise description of the POST method)

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 05 Jun 2007 00:07:08 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1180994828.14442.104.camel@henriknordstrom.net>
mån 2007-06-04 klockan 23:12 +0200 skrev Julian Reschke:

> This is related to a discussion we had a few weeks ago over on Atompub, 
> where there was an argument whether a server can just drop parts of the 
> PUT body, or actually implement PUT as some kind of PATCH (where PUT 
> would only modify parts of the existing resource).

My understanding of PUT:

You can use PUT to patch entities by doing a ranged PUT using
Content-Range together with If-Match using a strong validator. But I
don't expect many implementations to support this and would also expect
several to silently fail to do it properly even if there is a MUST
requirement to error if not understood.. (9.6 PUT, first paragraph, last

Note: As written the specs do not allow multipart/byteranges to be used
in PUT.

> I *think* the consensus was that when RFC2616 says "store" it really 
> means "store", so -- in general a server should not just do a partial 
> update of the request being identified.


> rfc2616bis-02 relaxes the original definition of POST, so my concern is 
> that by PUT referencing POST we also have relaxed the definition of PUT 
> as well (making it: the server may do *anything* it wants).

No, I don't see that PUT has been relaxed in any manner by the POST
changes. The definition is quite strict about the meaning of the request
entity in PUT.

But then I also don't really consider the POST changes as relaxing the
definition of POST, just cleaning it up to be more consistent with
itself. And I also consider the POST reference in the PUT description as
informative to remind the reader that there is a related method, and not
part of the formal definition of PUT. There is no SHOULD/MUST/MAY in


Received on Monday, 4 June 2007 22:07:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:42 UTC