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: Brian Smith <brian@briansmith.org>
Date: Mon, 19 Oct 2009 20:38:27 -0500
To: "'Roy T. Fielding'" <fielding@gbiv.com>
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: <001301ca5126$08b1fd50$1a15f7f0$@org>
Roy T. Fielding wrote:
> On Oct 19, 2009, at 12:43 PM, Brian Smith wrote:
> > Julian Reschke wrote:
> >> So my proposal would be to stay silent on this, and let the base
> >> spec define it.
> >
> > I agree, but IMO, there should *never* be a fallback to Last-Modified
> > because Last-Modified only has 1-second resolution. If the server
> > supports PATCH then it can definitely provide an ETag.
> 
> 1-second resolution is as good as nanosecond resolution as soon
> as that second is history, and in practice both are useless for
> tagging dynamic content that is generated during a response.

Not really. If you have nanosecond resolution then you can have
monotonically increasing (thus *unique*) timestamps on every resource.
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.

> 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).

Regards,
Brian
Received on Tuesday, 20 October 2009 01:39:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:12 GMT