linux@xxxxxxxxxxx wrote:
If someone feels ambitious, you can detect this condition automatically
by searching for a file that you know won't be there and seeing if you
get a 404 response to that.
To avoid punishing good servers, it would be nice to defer the test
until reciving the first corrupted object.
I'm not sure what the best "object that's not supposed to be there" is.
.git/objects/00/hoping-for-a-404-or-webadmin-should-fix
It has the right number of chars so it should fit in wherever a real
object name does but is obviously bogus anyways.
It could just be a random hash, or would a malformed object file name
be better?
A malformed object name is infinitely better. Otherwise we'd end up with
a wild guess that hits home some day, to much surprise and a bug-report
I wouldn't want to track. Not to mention the embarrassment when
explaining why that object-name was chosen.
(As an aside, I suspect this is all caused by Microsoft's "friendly HTML
error messages" invention.)
The body of the 404-page has absolutely nothing to do with it.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
: 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