Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. [...] > 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? 500 Internal Server Error doesn't look right (well, it can indicate bug in server code), but would git respond to correct error code other than 404 Not Found, like 405 Method Not Allowed, or 501 Not Implemented? -- Jakub Narebski Poland ShadeHawk on #git -- 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