From: Jakub Narebski <jnareb@gmail.com>
To: Lea Wiemann <lewiemann@gmail.com>
Cc: git@vger.kernel.org, Kay Sievers <kay.sievers@suse.de>
Subject: Re: [PATCH] gitweb: return correct HTTP status codes
Date: Mon, 16 Jun 2008 18:43:08 +0200 [thread overview]
Message-ID: <200806161843.09372.jnareb@gmail.com> (raw)
In-Reply-To: <48568D5C.5090909@gmail.com>
[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
next prev parent reply other threads:[~2008-06-16 16:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-15 21:15 [PATCH] gitweb: return correct HTTP status codes Lea Wiemann
2008-06-15 22:48 ` Jakub Narebski
2008-06-16 15:57 ` Lea Wiemann
2008-06-16 16:43 ` Jakub Narebski [this message]
2008-06-16 21:49 ` Lea Wiemann
2008-06-16 22:34 ` Jakub Narebski
2008-06-17 13:53 ` Lea Wiemann
2008-06-16 22:38 ` Junio C Hamano
2008-06-17 14:04 ` Lea Wiemann
2008-06-17 14:33 ` Jakub Narebski
2008-06-17 22:28 ` Lea Wiemann
2008-06-17 22:54 ` Jakub Narebski
2008-06-17 23:47 ` Lea Wiemann
2008-06-18 0:12 ` Jakub Narebski
2008-06-18 1:25 ` Lea Wiemann
2008-06-18 7:35 ` Jakub Narebski
2008-06-16 23:37 ` Jakub Narebski
2008-06-18 0:15 ` [PATCH] gitweb: standarize " Lea Wiemann
2008-06-19 0:51 ` [PATCH v2] " Jakub Narebski
2008-06-19 19:08 ` Lea Wiemann
2008-06-19 20:03 ` [PATCH v3] " Lea Wiemann
2008-06-19 20:25 ` Lea Wiemann
2008-06-19 22:37 ` Jakub Narebski
2008-06-20 0:48 ` Junio C Hamano
2008-06-19 22:22 ` [PATCH v2] " Jakub Narebski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200806161843.09372.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=kay.sievers@suse.de \
--cc=lewiemann@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).