Tay Ray Chuan <rctay89@xxxxxxxxx> writes: > Just to clarify: the "check" of CURLE_OK in http-walker.c::fetch_index() > in v1.6.3 is fundamentally different from the check we have in 48188c2 > (http-walker: verify remote packs, 2009-06-06). > > The first "check" is a full-blooded GET request, and we do get back > actual data (in this case, the pack index file). The second check isn't > a GET request, just an inconsequential HEAD request; we don't get back > any real data. Yeah, I realized after I wrote the message you are responding to and ran some experiments with github repository myself to see for some of their URLs HEAD gives 500 when GET gives the contents just fine. Tom, sorry to have given a confusing list of issues in my earlier message. Please disregard it. The only funny your HTTP server folks may want to look into is that GET request to fetch the following URL gives the contents just fine, but HEAD request to it results in an Internal Server Error. http://github.com/tekkub/addontemplate.git/objects/pack/pack-382c25c935b744e909c749532578112d72a4aff9.pack Sorry about the confusion. > Agreed. I didn't intend my patch to loosen up error checking, merely to > be clearer about what we're looking for. If read in another context > (separate from fixing cloning over github.com), my patch can be seen as > one that clarifies the verify-remote-pack check: > > Case 1: A 404 is received. The pack file is not available, so we stop. > > Case 2: Our check failed, due to some reason (request failed, > unauthorized, etc). Nothing conclusive about availabilty of > file. Continue anyway. I am torn about this. On one hand, if we are going to treat such a half failure as nothing conclusive, I do not see a point to keep that check to begin with. On the other hand, if a HEAD request to a URL results in an unauthorized, what plausible excuse the server operator could give for allowing a GET request to the same URL? If we are going to keep the check if *.pack that corresponds to the *.idx will be available, shouldn't we trust whatever check we perform? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html