On 27/03/2012, at 1:04 PM, Daz DeBoer wrote: > On 27 March 2012 05:43, Luke Daley <[email protected]> wrote: > > On 27/03/2012, at 6:04 AM, Szczepan Faber wrote: >> 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). >> >> I'm sold. > > Interestingly, I hit a quirk of this approach testing my changes. > > We have an integration test that publishes a module then changes it instantly > (in < 1 sec). HTTP dates have second fidelity. The test was changing the > content, without changing the file length and the modification date > difference was < 1 sec. A joy to debug, obvious in hindsight. > > Ouch. The test method publishWithChangedContent() should probably change the > content length, I guess. In the real world I'm not sure if we need to > differentiate resources published with the same content length in the same > second…
I think you're right. I think we can take this risk. If we also use eTags then we'll be fine anyway (if the server issues eTags). > This is pretty edge surely but I wonder if we should change our strategy. We > could potentially prefer eTags and only fallback to last mod + content length > if the server doesn't advertise eTags. We could then use if-none-match and > avoid the extra head request. > > One problem here is that we expect servers to be compliant and implement > if-none-modified properly, which they don't all do (I'm looking at you > Artifactory). One option could be that we record the value of the “server” > header in the external resource metadata and use it to make decisions. We > might be starting to get too complex here though for negligible benefit. > > Using eTags is a good idea, but does it need to change our strategy of using > a HEAD request for comparison? Couldn't we treat it as another opaque > identifier to compare between requests, just like the combination of > timestamp + content length? Then server compliance is not an issue. You're right, and Adam suggested this earlier which I missed. It's unfortunate though because it does mean 1 more request. Though that's only if the artifact has changed, in which case I think the overhead is acceptable. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
