- From: Sylvain Hellegouarch <sh@defuze.org>
- Date: Thu, 10 Aug 2006 08:09:30 +0100 (BST)
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: sh@defuze.org, "HTTP Working Group" <ietf-http-wg@w3.org>
> Sylvain Hellegouarch schrieb: >> 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. > > Specifying that behavior would be incompatible with RFC2616, which > already allows a server to rewrite the content without returning it in > the response body. > > And, as Cyrus pointed out, returning the new body is expensive, and most > of the times completely useless (which I tried to demonstrate in > <http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-00.html#simple.authoring>). > To optimize the case where the client indeed *wants* the new content, we > would need a new way to signal that, such as a new request header > (feedback appreciated). > Both are fair points. I am still not convinced by the way Entity-Tranform is specified though. It seems over complicated. Why not defining the Entity-Transform header has follow: Entity-Transform = "Entity-Transform" ":" media-type Thus taking benefit from the existing IANA registration for what you call token in your proposal of the header. At least in that case the user-agent would know precisely how the server has transformed the request entity and the impact of that extension would be minimum. If the header was not present in the response it would mean the server did not transform the entity. - Sylvain
Received on Thursday, 10 August 2006 07:09:38 UTC