- 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
> 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. Yep. > 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 http://www.ics.uci.edu/~fielding/
Received on Sunday, 18 August 1996 01:35:13 UTC