W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: weak etags vs PATCH, was: Fwd: New Version Notification - draft-dusseault-http-patch-15.txt

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 19 Oct 2009 19:20:03 -0700
Cc: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Lisa Dusseault'" <lisa.dusseault@gmail.com>, "'Mark Nottingham'" <mnot@mnot.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <51559A83-BEEC-4914-BD5E-80BC64DF8E29@gbiv.com>
To: Brian Smith <brian@briansmith.org>
On Oct 19, 2009, at 6:38 PM, Brian Smith wrote:
> Not really. If you have nanosecond resolution then you can have
> monotonically increasing (thus *unique*) timestamps on every resource.

The only way you are going to get that is by restricting the
resource to a single server, single CPU, and critical sections
or locking.  And if you are going to go to that trouble, you
might as well have a strong versioning back-end with real etags.

> Actually, I often implement ETags that way. With one-second  
> resolution you
> can get something similar by sleeping during an edit until the  
> timestamp
> changes, I guess.

Not very popular with customers.

>> Using last-modified as a fallback is always better than not
>> using any conditional at all.
> Yes, well I was thinking that the server should just refuse all  
> requests
> without an If-Match header. Unconditional PATCH makes very little  
> sense for
> most uses. I guess section 2.2 already allows a server to do that (by
> returning a 409 response).

There is nothing stopping the patch format from including a
strong version indicator, content hash, or even a context-based
collaborative merging mechanism in the format itself.  The notion
that PATCH must use conditionals is absurd given that the original
idea came from the patch command that intentionally supports
non-overlapping edits in any sequence.

Received on Tuesday, 20 October 2009 02:20:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC