Nick Hengeveld <nickh@xxxxxxxxxxxx> writes: > Seems like there are three cases to worry about: > > 1) the server returns a 200 status and a text/html response instead of a > 404, and the server's default content type is not text/html > 2) the server returns a 200 status and a text/html response instead of a > 404, and the server's default content type is text/html > 3) the server returns a corrupt object from the repository > I don't think there's a way to distinguish between #2 and #3, so all we > can really do is display as helpful an error message as possible. The code behaves correctly the same way whether the server says 404 or 200 with human readable "No such object", and this is just for formatting error messages, and to be honest I do not really care at this point. I think the existing error message at the end of transfer we added recently should be sufficient. > On a related note, I noticed that http-fetch will continue to try > inflating/sha1_updating the response after an inflate error has been > detected. It's probably not a huge deal, but we could just error out > immediately at that point or at least stop the unnecessary processing. That would probably be more helpful. - : 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