W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

From: Jamie Lokier <jamie@shareable.org>
Date: Fri, 21 May 2004 15:00:39 +0100
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: ietf-http-wg@w3.org, Lisa Dusseault <lisa@osafoundation.org>
Message-ID: <20040521140039.GB27886@mail.shareable.org>

Alex Rousskov wrote:
> > 4. The PATCH method won't cause the ETag to change if the patched
> > entity is identical to the one before patching.
> Whether the ETag changes depends on whether it reflects things other
> than raw octet composition. For example, if ETag reflects last "write
> access" time, it may change even if octets remain the same.

I should have said "the PATCH method *needn't* cause the ETag to change".

The ETag may reflect the Last-Modified time, which needn't change if
the content and entity headers aren't changed by the patch.  It's a
matter of server policy.  I think at least some unix servers won't
alter the mtime of a file if you open it for writing but don't write
anything - as some patch operations conceivably might do.

Also, even if the server definitely does recording the time of the
patch as the last write access time, and uses that as part of the
ETag, the time used for the Etag usually has a granularity (often 1
second).  So it might still not change the ETag.

If a server is only using the POSIX mtime field for an ETag then it
should probably not call it a strong ETag.  However if it uses mtime
and also the a strong checksum of the file to construct the ETag then
that's a fine strong ETag - which needn't change as a result of PATCH.

-- Jamie
Received on Friday, 21 May 2004 10:00:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:25 UTC