- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 30 Nov 2006 14:50:29 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Ted Hardie <hardie@qualcomm.com>, Jim Whitehead <ejw@soe.ucsc.edu>, Wilfredo Sánchez Vega <wsanchez@wsanchez.net>, Cullen Jennings <fluffy@cisco.com>, Mark Nottingham <mnot@mnot.net>
> On Nov 28, 2006, at 4:27 PM, Julian Reschke wrote:
>
>> The Xythos client always assumes that content isn't rewritten. And
>> if no ETag is returned, it uses the Last-Modified date as cache
>> key. So it's already broken with respect to servers that have to
>> rewrite.
>>
>> Roy never made a proposal, and didn't answer when asked for
>> clarification/confirmation.
I don't like repeating myself over and over again just because you
want to add an unnecessary feature to HTTP.
My opinion hasn't changed -- the extension is completely unnecessary,
RFC 2616 already defines what sending an etag on PUT means,
and every single relevant case can be handled by a simple clarification.
My proposal was:
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.
I am quite sure that none of the server vendors will care about the
addition of that clarification 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.
My proposal does solve every single case that has been described so far,
including repeatable server-modifications such as normalization, and
works with existing clients.
In regard to Apache mod_dav's use of weak entity tags, that is a
separate
issue and can be fixed without changing HTTP at all. It is merely an
implementation quirk having to do with the way mod_dav reuses the
file space as a storage mechanism (and thus a separate handler for GET).
I can very easily turn it off, as can anyone with access to the config
files. The right solution, though, is to use a property-based back-end
and store the MD5 on write, which would allow the weak designation to be
removed and actually solve the real problem of clients wanting a strong
etag returned from PUT. Patches are welcome.
....Roy
Received on Thursday, 30 November 2006 22:51:18 UTC