gitweb testing with non-apache web server

gitweb testing with non-apache web server

[Marc Singer]

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.

Re: gitweb testing with non-apache web server

[Jakub Narebski]

<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).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: gitweb testing with non-apache web server

[Marc Singer]

On Thu, Aug 03, 2006 at 10:18:07AM +0200, Jakub Narebski wrote:
> <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.


> 
> -- 
> 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

Re: gitweb testing with non-apache web server

[Jakub Narebski]

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

Re: gitweb testing with non-apache web server

[Marc Singer]

On Thu, Aug 03, 2006 at 05:48:11PM +0200, Jakub Narebski wrote:
> 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).


> 
> -- 
> 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

Re: gitweb testing with non-apache web server

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 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?

Re: gitweb testing with non-apache web server

[Jakub Narebski]

Junio C Hamano wrote:

> 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

Re: gitweb testing with non-apache web server

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> 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?

Re: gitweb testing with non-apache web server

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

hoi :)

On Thu, Aug 03, 2006 at 12:41:20PM -0700, Junio C Hamano wrote:
> 	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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: gitweb testing with non-apache web server

[Sam Vilain]

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.

> 
> 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

Re: gitweb testing with non-apache web server

[Blu Corater]

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. 

-- 
Blu.

Re: gitweb testing with non-apache web server

[Marc Singer]

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.

> 
> -- 
> 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

Re: gitweb testing with non-apache web server

[Blu Corater]

On Thu, Aug 03, 2006 at 09:22:41AM -0700, Marc Singer wrote:
> 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.

Re: gitweb testing with non-apache web server

[Marc Singer]

On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
> 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.

Re: gitweb testing with non-apache web server

[Francis Daly]

> 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

Re: gitweb testing with non-apache web server

[Marc Singer]

On Fri, Aug 04, 2006 at 12:55:36AM +0100, Francis Daly wrote:
> > 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.

Re: gitweb testing with non-apache web server

[Francis Daly]

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

Re: gitweb testing with non-apache web server

[Marc Singer]

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.