[Fast reply, I will reply more in depth later] Lea Wiemann wrote: > Jakub Narebski wrote: >> Lea Wiemann wrote: >>> open my $fd, "-|", git_cmd(), "ls-tree", $base, "--", $path >>> - or die_error(undef, "Open git-ls-tree failed"); >>> + or die_error(500, "Open git-ls-tree failed"); >> >> Should we really use "500 Internal Server Error" here? Usually this >> would be not an error at all, but wrong parameters to git command, >> i.e. it is _user_ who erred, not some error on _server_ side. > > You cannot tell for sure -- all you know here is that the command > somehow failed when it shouldn't have, and so all you can give is 500; > see below. I don't think we should apply reasoning like "most commonly > it's a wrong hash, so let's return 404" -- we don't know, and we > shouldn't assume. Well, we could, perhaps, examine stderr (or redirect it to stdout and examine upon error) to check what was the error. Or when/if gitweb start to use Git.pm methods, examine catched Error (for example "fatal: bad revision '$hash'" would mean "404 Not Found" revision). 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, i.e. URL I have entered, or handcrafted, or magled. That is IMVHO *very* important difference, and why I am against using "500 Internal Server Error" as catch-all; I can agree that "403 Forbidden" (which is from the times where gitweb was developed as separate project by Kay Sievers, old, old times of v056) is better left for disabled features[*1*], and "404 Not Found" is better catch-all. Kay, do you remember why "403 Forbidden" was used as default catch-all gitweb HTTP error status code? > > probably me, Petr Baudis, John Hawley, perhaps Luben Tuikov > > I wouldn't want to Cc people if I don't address them personally -- e.g. > neither Petr nor John are currently working on gitweb, so flooding their > mailboxes might seem a little rude; if they're interested they can > always filter for subjects. (Unless someone requests to always be CC'ed > of course.) O.K. although I have though that as John is your GSoC mentor, he might be interested gitweb caching related posts. But this is something better made agree with him. BTW. I got three copies of this email: was it you fighting VGER anti-spam filter? -- Jakub Narebski Poland -- 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
