- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 19 Oct 2009 19:20:03 -0700
- To: Brian Smith <brian@briansmith.org>
- 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>
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. ....Roy
Received on Tuesday, 20 October 2009 02:20:35 UTC