On 26/03/2012, at 9:22 AM, Luke Daley wrote: > > On 25/03/2012, at 11:16 PM, Adam Murdoch <[email protected]> wrote: > >> We should certainly tidy up the behaviour for 1.0 (use a HEAD request, >> compare content-length and last-modified-time > > I'm not clear on why this is better than if-modified-since, except for > misbehaving servers.
It's more robust (which is why we use it for checking whether local files are up-to-date): * I roll-back the state of the repository (or some subset of the repository). For example, say I have a repo backed by svn, and I do an svn checkout of an earlier revision. Or I restore a repo from a backup. In both cases, the current artefact may now have a timestamp that is earlier than the previous time we fetched the artefact. * I change the system clock between publications of a changing artefact. Say I publish an artefact, then move the clock back 1 hour, then publish the artefact again. The timestamp on the newer artefact is earlier than the older artefact. * I publish a changing artefact multiple times within a short period of time. For example, if I publish an artefact twice to a repo backed by a filesytem with a 2 second timestamp resolution, I may end up with the same timestamp on both artefacts if the publications happen within 2 seconds of each other. In short, relative comparison of timestamps is always a bad idea. We should be treating them as opaque identifiers (i.e. can only check for equality) and never on their own (i.e. include length as well). Also, by doing a separate HEAD request, we can also make use of etags, without caring if the server honours the if-none-match header. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
