Jakub Narebski wrote:
Well, we could, perhaps, examine stderr (or redirect it to stdout and examine upon error) to check what was the error.
We don't have to -- gitweb's current (suboptimal) error checking is because it doesn't interface with git very well. The API I'm writing will fix this (i.e. provide proper feedback in all cases) so we'll have more specific status codes. IOW, we'll be able to differentiate between 500 and 404. Trust me on this one. ;-)
But I think in all, or almost all cases, the source is wrong parameters in URL. Now, returning 5xx _server_ error would make me want to email webmaster about error on his/her server, while 4xx _user_ error would make me examine my input
Since the status codes will get better (more accurate) anyway, I care more about correctness than practicalities right now (and I'm convinced that only 500 is correct in the cases we're talking about). That said, if you really want 404s in there, go ahead and send a follow-up patch, I won't object.
BTW. I got three copies of this email: was it you fighting VGER anti-spam filter?
Yup. Apparently it simply greps for Content-TypXe: text/hXtml. *shakes head* :-)
-- Lea -- 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
