- From: Sylvain Hellegouarch <sh@defuze.org>
- Date: Wed, 09 Aug 2006 22:35:28 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Hi Julian, Julian Reschke a écrit : > > Hi, > > we've been discussing the interpretation of ETags returned upon an > HTTP PUT request for some time now. Jim Whitehead started work on an > Internet Draft discussing this topic in February (see > <http://greenbytes.de/tech/webdav/draft-whitehead-http-etag-00.html>), > but unfortunately we didn't make any progress since. > > Personally, I think that we really need a very minor clarification, > plus a simple new feature to help clients that want to avoid a > re-fetch after sending the content. I therefore decided to write up my > own draft. It summarizes the situation (as RFC2616 is concerned), > proposes one clarification to RFC2616 (as mentioned in > <http://lists.w3.org/Archives/Public/ietf-http-wg/2006JanMar/0003.html>), > and also proposes that minor new feature (a new response header). > > Feedback appreciated. I mean it. We really should resolve this, as two > drafts in front of the IESG already make contradicting requirements. > > HTML at > <http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-00.html>. > > I'm not sure the Entity-Transform header is needed since you might as well achieve the same result by using both the status code and the content type of the returned entity. Server does not modify the resource => Sends a 204 No Content Server does modify the resource => Sends a 200 and the newly created entity with its new media-type. That way the user agent knows if the resource has been modified and how. - Sylvain
Received on Wednesday, 9 August 2006 21:36:01 UTC