W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: 201 created on PUT Method etc

From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Sun, 18 Aug 1996 01:12:58 -0700
To: "John C. Mallery" <jcma@ai.mit.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9608180113.aa07253@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1397
> Henrik and I found a problem with the 1.1 put when
> testing against the linemode browser.
> When the document exists, I send back 204 with
> entity headers including the content-version.
> This works fine because there is no body.


> However, when a new entity is created, I send
> 201 but cannot send the entity headers on the new
> resource because there can be a separate entity body.
> The result is that the client will have to do an additional
> head to know the resulting entity version etc etc.
> It seems to me that, in the first case, the "200 or 204" in the
> spec should be dropped the 200.

Nope -- the 200 is necessary for those cases where the server
wants the client reload the resource before making more changes.

> In the second case, it seem to me that either 201 should not
> return a body or a different return code like a 204 should be
> used, thus obviating the need to do an extra operation to collect
> the information needed to handle versioning.

201 provides the opportunity for the server to say: "Okay, I did that,
here are pointers to what was done and perhaps something else you
need to do."  I can see why you might want 204 to be allowed as well,
and I can't remember why only 201 is required in the spec.

> Additionally, the content-version and derived-from headers should
> be moved into the spec body.

Too late -- that was postponed to HTTP/1.2.  I would have liked them
in HTTP/1.1 as well.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Sunday, 18 August 1996 01:35:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC