Subject: Re: gitweb: false base href sent when integrated via reverse proxy and path_info is active

From: Jakub Narebski <[email-masked]>
Date: Sun, 28 Nov 2010 18:47:38 +0100

On Sun, 28 Nov 2010, Giuseppe Bilotta wrote:
> On Sun, Nov 28, 2010 at 5:27 PM, Jonathan Nieder <[email-masked]> wrote:
>> Hi Jakub et al,
>>
>> Daniel Reichelt wrote[1]:
>>
>>> I just noticed that integrating gitweb via reverse proxy is impossible when
>>> path_info is enabled in gitweb.conf. The base href sent on gitweb.cgi:3427
>>> contains the "internal" URL called by the reverse proxy mechanism, not the
>>> original one called by the user agent which makes it impossible for the
>>> client to display CSS, images, etc...
>>>
>>> I suggest an additional config variable, e.g.
>>> $feature{'pathinfo'}{'basehrefoverride'} which could override the base href
>>> tag determinted by the cgi script (or disable sending a base href tag at all
>>> - at least I was able to achieve my desired setup by adjusting the URLs for
>>> CSS etc in gitweb.conf to fitting absolute URLs).
>>
>> Any advice for Daniel?  Is it a good idea?
> 
> I'm not familiar with the way reverse proxies operate. Is there some
> information that the script can scrape to understand that its request
> is being reverse-proxied? Or are there options that the reverse
> proxies can be configured with to pretend that the URL is not being
> rewritten? These would be better solutions.
> 
> Lacking that, a plain
> 
> our $base_url  = 'whatever';
> 
> in the gitweb config should probably work, as the gitweb config is
> evaluated _after_ the internal URI variables are set. Can the bug
> submitter confirm that this does indeed work?

See also gitweb/README, the "Gitweb config file variables" section:

 * $base_url
   Base URL for relative URLs in pages generated by gitweb,
   (e.g. $logo, $favicon, @stylesheets if they are relative URLs),
   needed and used only for URLs with nonempty PATH_INFO via
   <base href="$base_url">.  Usually gitweb sets its value correctly,
                             ^^^^^^^
   and there is no need to set this variable, e.g. to $my_uri or "/".

The key word here is "usually" ;-)

-- 
Jakub Narebski
Poland