- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 12 Sep 2006 19:52:08 -0700
- To: Lisa Dusseault <lisa@osafoundation.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sep 12, 2006, at 7:00 PM, Lisa Dusseault wrote: > Yes, this is a good analysis. I know there are significant client > deployments based on assuming no server-rewriting. I am not aware > of server deployments that do rewriting and return strong ETags. > I'm thus quite confident about where the interop advantage lies. I agree. As I said last time, the easier solution is to simply require that ETag in a response to PUT means that the client can use that entity tag in future conditional requests (that includes IMS, If-Match, and Range- based conditional requests). There is absolutely no reason for the server to send an ETag on a PUT response if the server does not intend to support that functionality, and I am quite sure that none of the server vendors will care provided that the requirement is properly stated as an interface constraint and not an implementation constraint. OTOH, the mechanism for how the server "stores" the representation, whether or not it is stored byte-for-byte, and how a server might otherwise manage to accomplish the feat of handling a conditional request without preserving byte-level equality is none of our business and should never appear in an IETF specification regarding HTTP. ....Roy
Received on Wednesday, 13 September 2006 02:52:19 UTC