On 30/03/2012, at 6:04 AM, Adam Murdoch wrote: > > On 30/03/2012, at 1:19 PM, Daz DeBoer wrote: > >> On 29 March 2012 17:31, Adam Murdoch <[email protected]> wrote: >> * We need to deal with the case where a server does not handle the HEAD >> request (e.g. stuff hosted at googlecode). >> >> Good point. That's something we don't currently handle. Although >> googlecode.com is broken, and it would be nice to trust the HEAD request on >> other servers. That would mean coding an exception algorithm for googlecode, >> I guess. Not fundamentally different from knowing etag==sha1 for Nexus, or >> using the special Artifactory SHA1 header, I guess. >> Daz > > > There are some other cases where the HEAD request fails but the GET request > would succeed, that we should think about. One example is where you get a 403 > 'forbidden' or a 405 'method not supported' response to the HEAD request, > regardless of whether the resource exists or not (can't recall exactly where > this was happening; it's in jira somewhere). > > I think for these response codes, we should continue on to the GET SHA1 > request
Agreed. If we get a 403 or 405, we continue on. Any other 4xx (except 404 discussed below) response we should probably log a WARN and move on. It would be really nice to be able to stop on a 404. Google Code is clearly breaking spec here. Their relevant (4 year old!) issue is here: http://code.google.com/p/support/issues/detail?id=660 I'd rather try putting some pressure on them to fix this first before resigning. If we do resign to the fact that they won't fix it, do we put in a workaround just for GoogleCode? Or do we not trust 404s at all? Not trusting them means another 2 get requests when the resource doesn't exist. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
