threads / discuss / 5102

gitweb testing with non-apache web server

Subject: gitweb testing with non-apache web server

## tl;dr

18 messages between Aug 3, 2006 and Aug 4, 2006.

replies: 17people: 7as markdown or json

Marc Singer· Aug 3, 2006, 07:54 UTC · lore

I would like to use gitweb with the Cherokee web server because the host that I have on hand has very limited RAM, 32MiB. Neither the version of gitweb available on Debian (v264) nor the latest in the git repo works.

I did some debugging on the latest repo version.  The lines
  our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
  if (defined $project) {
     ...
are being executed even though the url is
  http://server/git

I think that the problem is that Cherokee translates the request URL into

  http://server/git/

which means that the $ENV{'PATH_INFO'} is the string "/" insted of being undefined.

The error I'm seeing is that the request path is forbidden, but I suspect that this is some sort of misunderstanding between the web server and the script.

So, I wonder if someone who has a working gitweb would be willing to test with Cherokee or some other resource conservative web server.

Cheers.
Jakub Narebski· Aug 3, 2006, 08:18 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

<opublikowany i wysłany>
Marc Singer wrote:
Show 17 quoted lines
> I did some debugging on the latest repo version.  The lines
> 
>   our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
>   if (defined $project) {
>      ...
> 
> are being executed even though the url is
> 
>   http://server/git
> 
> I think that the problem is that Cherokee translates the request URL
> into
> 
>   http://server/git/
> 
> which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> being undefined.
Try changing
my $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
if (defined $project) {
        $project =~ s|^/||; $project =~ s|/$||;
to

my $project = ($cgi->param('p') || $ENV{'PATH_INFO'}); $project =~ s|^/||; $project =~ s|/$||; if (defined $project && $project) { 

(and send patch if it works, please).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Marc Singer· Aug 3, 2006, 15:34 UTC · re: Jakub Narebski · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 10:18:07AM +0200, Jakub Narebski wrote:
Show 36 quoted lines
> <opublikowany i wys?any>
> 
> Marc Singer wrote:
> 
> 
> > I did some debugging on the latest repo version.  The lines
> > 
> >   our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> >   if (defined $project) {
> >      ...
> > 
> > are being executed even though the url is
> > 
> >   http://server/git
> > 
> > I think that the problem is that Cherokee translates the request URL
> > into
> > 
> >   http://server/git/
> > 
> > which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> > being undefined.
> 
> Try changing
> 
> my $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> if (defined $project) {
>         $project =~ s|^/||; $project =~ s|/$||;
> 
> to
> 
> my $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> $project =~ s|^/||; $project =~ s|/$||;
> if (defined $project && $project) {     
> 
> (and send patch if it works, please).

That isn't enough. I did something like that when I was exploring the script. While the change *does* eliminate the 403 error, it doesn't make the rest of the script work properly. All of the links return to the same page that lists the projects.

Show 11 quoted lines
> 
> -- 
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jakub Narebski· Aug 3, 2006, 15:48 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

Marc Singer wrote:
> That isn't enough.  I did something like that when I was exploring the
> script.  While the change *does* eliminate the 403 error, it doesn't
> make the rest of the script work properly.  All of the links return to
> the same page that lists the projects.

Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all links use 'p=$project', not PATH_INFO...

Are you sure you did changes mentioned in earlier post?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Marc Singer· Aug 3, 2006, 16:20 UTC · re: Jakub Narebski · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 05:48:11PM +0200, Jakub Narebski wrote:
Show 11 quoted lines
> Marc Singer wrote:
> 
> > That isn't enough.  I did something like that when I was exploring the
> > script.  While the change *does* eliminate the 403 error, it doesn't
> > make the rest of the script work properly.  All of the links return to
> > the same page that lists the projects.
> 
> Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
> links use 'p=$project', not PATH_INFO...
> 
> Are you sure you did changes mentioned in earlier post?

Yes. I think that there is something else awry as well. Note that with the change you suggested, the latest script functions at the same level as the latest from the repo.

TBPH, I've never found a good way to debug CGI scripts. I just want to see what is going on and that's hard considering the fact that the server behavior seems to be a crucial component. When I run the script stand-alone, I see the results I expect (with some errors about the CGI object missing some parameters).

Show 11 quoted lines
> 
> -- 
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Junio C Hamano· Aug 3, 2006, 18:21 UTC · re: Jakub Narebski · lore

Re: gitweb testing with non-apache web server

Jakub Narebski <jnareb@gmail.com> writes:
Show 11 quoted lines
> Marc Singer wrote:
>
>> That isn't enough.  I did something like that when I was exploring the
>> script.  While the change *does* eliminate the 403 error, it doesn't
>> make the rest of the script work properly.  All of the links return to
>> the same page that lists the projects.
>
> Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
> links use 'p=$project', not PATH_INFO...
>
> Are you sure you did changes mentioned in earlier post?

Well, more importantly, why would we do something like this in the first place?

Wouldn't it be a lot better to just rip out PATH_INFO stuff, especially since all pages the script generates use ?p=$project to pass that information around and never uses PATH_INFO?

Jakub Narebski· Aug 3, 2006, 18:37 UTC · re: Junio C Hamano · lore

Re: gitweb testing with non-apache web server

Junio C Hamano wrote:
Show 14 quoted lines
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>
>> Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
>> links use 'p=$project', not PATH_INFO...
>>
>> Are you sure you did changes mentioned in earlier post?
> 
> Well, more importantly, why would we do something like this in the first 
> place?
> 
> Wouldn't it be a lot better to just rip out PATH_INFO stuff,
> especially since all pages the script generates use ?p=$project 
> to pass that information around and never uses PATH_INFO?

The PATH_INFO is here because it is easier to edit parameters by hand when the most important one, the project to examine, can be passed as PATH_INFO.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Junio C Hamano· Aug 3, 2006, 19:41 UTC · re: Jakub Narebski · lore

Re: gitweb testing with non-apache web server

Jakub Narebski <jnareb@gmail.com> writes:
Show 11 quoted lines
> Junio C Hamano wrote:
>
>> Well, more importantly, why would we do something like this in the first 
>> place?
>> 
>> Wouldn't it be a lot better to just rip out PATH_INFO stuff,
>> especially since all pages the script generates use ?p=$project 
>> to pass that information around and never uses PATH_INFO?
>
> The PATH_INFO is here because it is easier to edit parameters by hand when
> the most important one, the project to examine, can be passed as PATH_INFO.
Huh?  I do not get that.

Suppose I am looking at my repository. I visit there from my Firefox and see this in the location bar:

	http://www.kernel.org/git/?p=git/git.git;a=summary

Now I would want to check if there are updates to gitk. So I click on the location bar, and edit it to:

	http://www.kernel.org/git/?p=gitk/gitk.git;a=summary
(that's two insertions of 'k').
Now with PATH_INFO, how exactly is this easier?
Martin Waitz· Aug 3, 2006, 20:14 UTC · re: Junio C Hamano · lore

Re: gitweb testing with non-apache web server

hoi :)
On Thu, Aug 03, 2006 at 12:41:20PM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> 	http://www.kernel.org/git/?p=gitk/gitk.git;a=summary
> 
> (that's two insertions of 'k').
> 
> Now with PATH_INFO, how exactly is this easier?
well, editing is not easier, but you can do other nice things.

On git.admingilde.org I have set up apache to serve the contents of my git repositories for all the well-known git repository URLs (*.git/objects/*, *.git/refs/*, ...) and to call gitweb for all other URLs. That way I get the exact same URLs for both gitweb and http:// clone (and even for git://, just change the protocol name).

I really think that it is very handy that you can give out a repository URL and any user can just click on it and get the summary page of this project.

I'm sure that it is possible to transfer the PATH_INFO into a p= parameter through URL rewrite rules, but it is much easier to set up if gitweb can directly grok appended paths.

I even changed the old gitweb to hand out links which used PATH_INFO rather than the p= parameter so that the URLs looked nicer. If there is interest in such a feature then I can do these changes again.

-- 
Martin Waitz
Sam Vilain· Aug 3, 2006, 11:42 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

Marc Singer wrote:
> I would like to use gitweb with the Cherokee web server because the
> host that I have on hand has very limited RAM, 32MiB.  Neither the
> version of gitweb available on Debian (v264) nor the latest in the git
> repo works.
Marc,

I use lighttpd on utsl.gen.nz, which is only a wee box, too. I hacked FastCGI support into gitweb.cgi, my changes are available at git://utsl.gen.nz/gitweb (gitweb url at http://utsl.gen.nz/gitweb/?p=gitweb).

I just set up the /git path to redirect to /git/ in the web server.
Sam.
Show 32 quoted lines
> 
> I did some debugging on the latest repo version.  The lines
> 
>   our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
>   if (defined $project) {
>      ...
> 
> are being executed even though the url is
> 
>   http://server/git
> 
> I think that the problem is that Cherokee translates the request URL
> into
> 
>   http://server/git/
> 
> which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> being undefined.
> 
> The error I'm seeing is that the request path is forbidden, but I
> suspect that this is some sort of misunderstanding between the web
> server and the script.
> 
> So, I wonder if someone who has a working gitweb would be willing to
> test with Cherokee or some other resource conservative web server.
> 
> Cheers.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Blu Corater· Aug 3, 2006, 15:56 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 12:54:03AM -0700, Marc Singer wrote:
Show 26 quoted lines
> I would like to use gitweb with the Cherokee web server because the
> host that I have on hand has very limited RAM, 32MiB.  Neither the
> version of gitweb available on Debian (v264) nor the latest in the git
> repo works.
> 
> I did some debugging on the latest repo version.  The lines
> 
>   our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
>   if (defined $project) {
>      ...
> 
> are being executed even though the url is
> 
>   http://server/git
> 
> I think that the problem is that Cherokee translates the request URL
> into
> 
>   http://server/git/
> 
> which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> being undefined.
> 
> The error I'm seeing is that the request path is forbidden, but I
> suspect that this is some sort of misunderstanding between the web
> server and the script.

I am using Cherokee+GitWeb and the behaviour observed is that http://server/git will return the default Cherokee index page, but http://server/git/, with a slash at the end, works. 

-- 
Blu.
Marc Singer· Aug 3, 2006, 16:22 UTC · re: Blu Corater · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 11:56:03AM -0400, Blu Corater wrote:
Show 31 quoted lines
> On Thu, Aug 03, 2006 at 12:54:03AM -0700, Marc Singer wrote:
> > I would like to use gitweb with the Cherokee web server because the
> > host that I have on hand has very limited RAM, 32MiB.  Neither the
> > version of gitweb available on Debian (v264) nor the latest in the git
> > repo works.
> > 
> > I did some debugging on the latest repo version.  The lines
> > 
> >   our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> >   if (defined $project) {
> >      ...
> > 
> > are being executed even though the url is
> > 
> >   http://server/git
> > 
> > I think that the problem is that Cherokee translates the request URL
> > into
> > 
> >   http://server/git/
> > 
> > which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> > being undefined.
> > 
> > The error I'm seeing is that the request path is forbidden, but I
> > suspect that this is some sort of misunderstanding between the web
> > server and the script.
> 
> I am using Cherokee+GitWeb and the behaviour observed is that
> http://server/git will return the default Cherokee index page, but
> http://server/git/, with a slash at the end, works. 
Will you share your Cherokee configuration script?
The links look like this:
  http://scarlet/g?p=bsp.git;a=summary
even when I start with 
  http://scarlet/g
or
  http://scarlet/g/
So, I'm not sure I understand what you are saying.
Show 7 quoted lines
> 
> -- 
> Blu.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Blu Corater· Aug 3, 2006, 19:21 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 09:22:41AM -0700, Marc Singer wrote:
Show 48 quoted lines
> On Thu, Aug 03, 2006 at 11:56:03AM -0400, Blu Corater wrote:
> > On Thu, Aug 03, 2006 at 12:54:03AM -0700, Marc Singer wrote:
> > > I would like to use gitweb with the Cherokee web server because the
> > > host that I have on hand has very limited RAM, 32MiB.  Neither the
> > > version of gitweb available on Debian (v264) nor the latest in the git
> > > repo works.
> > > 
> > > I did some debugging on the latest repo version.  The lines
> > > 
> > >   our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> > >   if (defined $project) {
> > >      ...
> > > 
> > > are being executed even though the url is
> > > 
> > >   http://server/git
> > > 
> > > I think that the problem is that Cherokee translates the request URL
> > > into
> > > 
> > >   http://server/git/
> > > 
> > > which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> > > being undefined.
> > > 
> > > The error I'm seeing is that the request path is forbidden, but I
> > > suspect that this is some sort of misunderstanding between the web
> > > server and the script.
> > 
> > I am using Cherokee+GitWeb and the behaviour observed is that
> > http://server/git will return the default Cherokee index page, but
> > http://server/git/, with a slash at the end, works. 
> 
> Will you share your Cherokee configuration script?
> 
> The links look like this:
> 
>   http://scarlet/g?p=bsp.git;a=summary
> 
> even when I start with 
> 
>   http://scarlet/g
> 
> or
> 
>   http://scarlet/g/
> 
> So, I'm not sure I understand what you are saying.
Here is the interesting part of my cherokee.conf
------------------------------------------
UserDir public_html {
    Directory / {
       Handler common
    }
    Directory /scm/ {
        Handler cgi {
                ScriptAlias /home/blu/bin/gitweb.cgi
        }
    }
}
-----------------------------------------

So, I have the gitweb.cgi executable in a bin directory on my home and I am telling Cherokee that when it sees the url http://server/~blu/scm/, it should execute /home/blu/bin/gitweb.cgi

If I request http://server/~blu/scm, Cherokee returns Cherokee's default index page. Only if I request http://server/~blu/scm/, Cherokee returns the expected output from gitweb.

Now, if I add 
    Directory /test/ {
	Handler cgi
    }
And copy gitweb.cgi to ~/public_html/test/, it seems there is no problem.

I can request http://server/~blu/test/gitweb.cgi or http://server/~blu/test/gitweb.cgi/ and get the expected gitweb output.

It looks more like a Cherokee problem to me, but I don't have time to investigate further right now.

-- 
Blu.
Marc Singer· Aug 3, 2006, 20:27 UTC · re: Blu Corater · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
Show 37 quoted lines
> Here is the interesting part of my cherokee.conf
> 
> ------------------------------------------
> UserDir public_html {
>     Directory / {
>        Handler common
>     }
> 
>     Directory /scm/ {
>         Handler cgi {
>                 ScriptAlias /home/blu/bin/gitweb.cgi
>         }
>     }
> }
> -----------------------------------------
> 
> So, I have the gitweb.cgi executable in a bin directory on my home and I
> am telling Cherokee that when it sees the url http://server/~blu/scm/, it
> should execute /home/blu/bin/gitweb.cgi
> 
> If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> index page. Only if I request http://server/~blu/scm/, Cherokee returns
> the expected output from gitweb.
> 
> Now, if I add 
> 
>     Directory /test/ {
> 	Handler cgi
>     }
> 
> And copy gitweb.cgi to ~/public_html/test/, it seems there is no problem.
> 
> I can request http://server/~blu/test/gitweb.cgi or
> http://server/~blu/test/gitweb.cgi/ and get the expected gitweb output.
> 
> It looks more like a Cherokee problem to me, but I don't have time to
> investigate further right now.

Hmm. I was hopeful when I saw that your configuration was different from mine. However, it seems to be something else. BTW, I'm running cherokee on ARM.

========================================
Directory / {
    Handler common
}
Directory /g/ {
    Handler cgi {
        Scriptalias /usr/lib/cgi-bin/git.cgi
    }
}
Directory /git/ {
    Handler cgi {
        Scriptalias /usr/lib/cgi-bin/gitweb.cgi
    }
}
========================================
gitweb.cgi is an old version.  git.cgi is the latest release.

I can see the project overview page, but all of the links bring me back to the same top-level page, no summary, not logs. I've verified that the web server's user can read the git repo. 

I don't doubt that this is a cherokee issue.
Cheers.
Francis Daly· Aug 3, 2006, 23:55 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

> Marc Singer wrote: 
> On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
Hi there,
> > If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> > index page. Only if I request http://server/~blu/scm/, Cherokee returns
> > the expected output from gitweb.
This is due to one apparent bug in Cherokee's Directory handling.
> I can see the project overview page, but all of the links bring me
> back to the same top-level page, no summary, not logs.  I've verified
> that the web server's user can read the git repo.

And this is due a a different, but arguably related, one. (The 301 handler ignores things it shouldn't.)

> I don't doubt that this is a cherokee issue.

Cherokee's handling of both Directory and Request sections with cgi and Scriptalias seems a bit funky (in different ways). If you want to use Cherokee configured this way, you may find it handy to add

$my_uri .= '/';

to your version of gitweb.cgi shortly after it is set -- that should break most of the generated links in a way that causes them to work with this server.

$my_url is only used in a few places, but it may be worth doing the same thing to it too.

Or use a web server which isn't broken in this particular way.
Good luck,
	f
-- 
Francis Daly        francis@daoine.org
Marc Singer· Aug 4, 2006, 06:11 UTC · re: Francis Daly · lore

Re: gitweb testing with non-apache web server

On Fri, Aug 04, 2006 at 12:55:36AM +0100, Francis Daly wrote:
Show 31 quoted lines
> > Marc Singer wrote: 
> > On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
> 
> Hi there,
> 
> > > If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> > > index page. Only if I request http://server/~blu/scm/, Cherokee returns
> > > the expected output from gitweb.
> 
> This is due to one apparent bug in Cherokee's Directory handling.
> 
> > I can see the project overview page, but all of the links bring me
> > back to the same top-level page, no summary, not logs.  I've verified
> > that the web server's user can read the git repo. 
> 
> And this is due a a different, but arguably related, one.  (The 301
> handler ignores things it shouldn't.)
> 
> > I don't doubt that this is a cherokee issue.
> 
> Cherokee's handling of both Directory and Request sections with cgi and
> Scriptalias seems a bit funky (in different ways).  If you want to use
> Cherokee configured this way, you may find it handy to add
> 
> $my_uri .= '/';
> to your version of gitweb.cgi shortly after it is set -- that should
> break most of the generated links in a way that causes them to work with
> this server.
> 
> $my_url is only used in a few places, but it may be worth doing the same
> thing to it too.
That does it.  
> 
> Or use a web server which isn't broken in this particular way.

:-) There doesn't seem to be much of the 'small' variety. Though now I'll look into lighttpd as well.

> 
> Good luck,
Cheers.
Francis Daly· Aug 4, 2006, 19:48 UTC · re: Marc Singer · lore

Re: gitweb testing with non-apache web server

On Thu, Aug 03, 2006 at 11:11:22PM -0700, Marc Singer wrote:
> On Fri, Aug 04, 2006 at 12:55:36AM +0100, Francis Daly wrote:
> > Or use a web server which isn't broken in this particular way.
> 
> :-) There doesn't seem to be much of the 'small' variety.  Though now
> I'll look into lighttpd as well.

I've had some success with thttpd, which is broken in a different way which doesn't appear to affect gitweb.

$ cp gitweb.cgi g $ thttpd -p 8080 -d . -c '/g' $ $BROWSER http://localhost:8080/g

for example.  Adjust the config to fit your overall site need, of course.

-h localhost, or -l /dev/null, or -D, may also be useful. There's a Fine Manual out there.

Good luck,
	f
-- 
Francis Daly        francis@daoine.org
Marc Singer· Aug 4, 2006, 07:30 UTC · re: Francis Daly · lore

Re: gitweb testing with non-apache web server

I found that lighttpd works well, though the configuration was a little more complex.

The recipe that works well is to make the URL
  http://server/git

to the gitweb.cgi script. I put the script and the CSS file in a directory, /var/lib/git/, and then put the following into the lighttpd configuration:

  # Serve GIT
  url.redirect    = ( "^/git$" => "/git/" )
  alias.url       += ( "/git/" => "/var/lib/git/" )
  $HTTP["url"]    =~ "^/git/" {
    cgi.assign            = ( ".cgi" => "" )
    index-file.names      = ( "gitweb.cgi" )
  }
Cheers.

← back to recent threads