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