git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] gitweb: return correct HTTP status codes

From
Jakub Narebski <jnareb@gmail.com>
Date
Jun 16, 2008, 16:43 UTC
Message-ID
<200806161843.09372.jnareb@gmail.com>
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:
Show 13 quoted lines
>>>  	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?
 
Show 7 quoted lines
> > 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
Previous: Lea WiemannNext: Lea Wiemann
Message 4 of 25 in “gitweb: return correct HTTP status codes”
  1. gitweb: return correct HTTP status codesLea Wiemann, Jun 15, 2008
  2. Jakub NarebskiJun 15, 2008
  3. Lea WiemannJun 16, 2008
  4. Jakub NarebskiJun 16, 2008
  5. Lea WiemannJun 16, 2008
  6. Jakub NarebskiJun 16, 2008
  7. Lea WiemannJun 17, 2008
  8. Junio C HamanoJun 16, 2008
  9. Lea WiemannJun 17, 2008
  10. Jakub NarebskiJun 17, 2008
  11. Lea WiemannJun 17, 2008
  12. Jakub NarebskiJun 17, 2008
  13. Lea WiemannJun 17, 2008
  14. Jakub NarebskiJun 18, 2008
  15. Lea WiemannJun 18, 2008
  16. Jakub NarebskiJun 18, 2008
  17. Jakub NarebskiJun 16, 2008
  18. gitweb: standarize HTTP status codesLea Wiemann, Jun 18, 2008
  19. Jakub NarebskiJun 19, 2008
  20. Lea WiemannJun 19, 2008
  21. gitweb: standarize HTTP status codesLea Wiemann, Jun 19, 2008
  22. gitweb: standarize HTTP status codesLea Wiemann, Jun 19, 2008
  23. Jakub NarebskiJun 19, 2008
  24. Junio C HamanoJun 20, 2008
  25. Jakub NarebskiJun 19, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.