You are here: Foswiki>Tasks Web>Item14063 (18 Feb 2017, GeorgeClark)Edit Attach

Item14063: Bootstrap fails to correctly detect path when mod_rewrite engine is disabled.

Priority: Urgent
Current State: Closed
Released In: 2.1.3
Target Release: patch
Applies To: Engine
Component: ConfigureBootstrap
Reported By: BramVanOosterhout
Waiting For:
Last Change By: GeorgeClark
Hi, I have worked around an annoying issue in the otherwise very nice installation of Foswiki. I struggled with this a while ago with the installation of 2.0.3, but did not have enough understanding of what was going on to make any sense of what happened. I got it to work eventually, following the same procedure as described below.

This time around, installing the distribution from GitHub I payed enough attention to discern a pattern. But i still don't know enough to chase it to a conclusion. All in all I am now the proud owner of a working site running Foswiki version v2.1.2, Release Foswiki-2.1.2, Plugin API version 2.4. Looks good!!!

My setup is:

  • Ubuntu 14.04.4 LTS
  • Apache/2.4.7 (Ubuntu) Server
  • perl 5, version 18, subversion 2 (v5.18.2)

Foswiki git is at:

/home/bram/devfoswiki/... where ... includes core

Apache uses

/var/www as the document root. In there is a soft link
  • devwiki -> /home/bram/devfoswiki/core
    • For instance (from the config file):
      ScriptAlias /devwiki/bin "/home/bram/devfoswiki/core/bin"

When I bootstrap foswiki with:
I get the bootstrap page with the configure link as:

When I click that link I get file not found. Clearly, because Apache cannot find anything at /var/www/bin/....

When I change it to (Adding a complete VIEWPATH and inserting /devwiki before /bin)
the configure page comes up. And from there it is plain sailing.

If I leave the VIEWPATH empty (because I did not understand what it was, or its significance, without studying the code):
I get a unstyled configure page heading and a lot of 404 in the apache access log trying to retrieve css and js from /pub instead of /devwiki/pub. An extract from the log demonstrating that the path to configure is now OK (its what I entered) and the path to ConfigurePlugin is not OK.: - - [07/May/2016:12:27:36 +1000] "GET /devwiki/bin/configure?VIEWPATH= HTTP/1.1" 200 3192 "-" "
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2" - - [07/May/2016:12:27:36 +1000] "GET /pub/System/ConfigurePlugin/reset.css HTTP/1.1" 404 527 "" "Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko

Somewhere my configuration fools the calculation of the path variables. But I cannot work out where.

Hope this helps someone, either as a work around or maybe it can be fixed?

Thanks for a good looking 2.1.2 release.

-- BramVanOosterhout - 07 May 2016

In your Apache error log should be a detailed debug report of the bootstrap: Phase 1 detects all the physical paths, and Phase 2 deals with the URL paths. In particular it ends up with:
AUTOCONFIG: Set DefaultUrlHost from HTTP_HOST 
AUTOCONFIG: ENGINE      is Foswiki::Engine::CGI
AUTOCONFIG: Calculated prefix  from SCRIPT_URI and SCRIPT_URL
AUTOCONFIG: Building Short URL paths using prefix  
AUTOCONFIG: Using ScriptUrlPath /bin
AUTOCONFIG: Using {ScriptUrlPaths}{view} 
AUTOCONFIG: Using PubUrlPath: /pub

If you could attach the complete Phase 1 & Phase 2 bootstrap logs just from your initial request to, that would be helpful. (Once you follow the generated like to configure, bootstrap runs for every json request, but the important one is the initial "view" execution where foswiki tries to figure out the required URL).

If you've already lost that log, it should be safe to temporarily rename your lib/LocalSite.cfg, run your default view url, and then rename it back.

-- GeorgeClark - 18 May 2016

And to answer your question about VIEWPATH, the purpose of that is to detect the "short URL" configuration. The path to view should have been detected as /devwiki, and the generated configure link should have been /devwiki/bin/configure?VIEWPATH=/devwiki The AUTOCONFIGURE log should hopefully have some hints about where it went wrong. Maybe it dereferenced a symlink to the physical path.

-- GeorgeClark - 18 May 2016

Thaks George, I recreated the log by renaming the LocalSite.cfg as you suggested. Attaching the log create a save error with a warning that there is an issue in the version control system. Here are the last 10 lines from the log
AH01215: AUTOCONFIG: Set DefaultUrlHost from HTTP_HOST 
AH01215: AUTOCONFIG: REQUEST_URI is /devwiki
AH01215: AUTOCONFIG: SCRIPT_URI  is (undef) 
AH01215: AUTOCONFIG: ENGINE      is Foswiki::Engine::CGI
AH01215: AUTOCONFIG: URI Prefix is 
AH01215: AUTOCONFIG: Building Short URL paths using prefix  
AH01215: AUTOCONFIG: Using ScriptUrlPath /bin 
AH01215: AUTOCONFIG: Using {ScriptUrlPaths}{view} 
AH01215: AUTOCONFIG: Using PubUrlPath: /pub 

-- BramVanOosterhout - 19 May 2016

Ah, now it works again. I'll try to attach the log and you may ignore my email.

-- BramVanOosterhout - 19 May 2016

Thanks. I think I have an idea about what's going on. IIRC the bootstrap code attempts to find the script filename in the url path, and it isn't quite getting it right with the symlinks and git based installation. I'll see if I can recreate it here and try to fix it. This area of the bootstrap code has to deal with a lot of combinations of server configurations. The fix will have to be pretty careful as there are a lot of special cases in this particular area.

-- GeorgeClark - 19 May 2016

Hi George, Glad to see you got the data. I am not convinced the issue is related to symlinks and git based installs. The first time i came across these symptoms was whilst installing Foswiki 2.0.3. A standard install in the same setup:
  • Ubuntu 14.04.4 LTS
  • Apache/2.4.7 (Ubuntu) Server
  • perl 5, version 18, subversion 2 (v5.18.2)
That installation was without symlinks in /var/www/Foswiki-2.0.3 and the apache config file states:
ScriptAlias /wiki/bin "/var/www/Foswiki-2.0.3/bin"
No symlinks, no git. But the same symptom: An incorrect link to configure on the bootstrap page with an empty ?VIEWPATH= parameter.

Hope this helps.

-- BramVanOosterhout - 19 May 2016

Got a reminder that this was waiting for feedback from me. Set the State back to New.

Sorry for the delay.

-- BramVanOosterhout - 05 Jun 2016

Any chance you could also attach your Apache configuration for your test? Did you use the ApacheConfigGenerator to build the config? If so, the first line of your config should be a URL that would let me rerun the generator with your setup.

I've been trying to recreate this, but so far I've been unsuccessful. I've tried it with and without short URLs enabled in the config. I always get the VIEWPATH set correctly with the /devwiki prefix. (in my case, just wiki, but still, the actual prefix should not matter).

-- GeorgeClark - 10 Sep 2016

Never mind ... I think I see what's causing this ... but no idea why. For some reason in my tests, SCRIPT_URI is set to the full URI to the view screen: 'SCRIPT_URI' => '', where on your test, SCRIPT_URI is undefined. Bootstrap needs to work around that particular situation.

Ah ha... SCRIPT_URI is set by mod_rewrite. Confirmed Bootstrap fails to detect short URLs if the rewrite engine is disabled. We definitely should handle this. Thanks for the report.

-- GeorgeClark - 10 Sep 2016

Hi George,

Glad you found the root cause.

Just to confirm: I did use the ApacheConfigGenerator.

-- BramVanOosterhout - 10 Sep 2016

Fixed in Item14180 branch. Needs merge.

-- GeorgeClark - 19 Sep 2016

ItemTemplate edit

Summary Bootstrap fails to correctly detect path when mod_rewrite engine is disabled.
ReportedBy BramVanOosterhout
Codebase 2.1.2, trunk
SVN Range
AppliesTo Engine
Component ConfigureBootstrap
Priority Urgent
CurrentState Closed
TargetRelease patch
ReleasedIn 2.1.3
Topic attachments
I Attachment Action Size Date Who Comment
apache_error.loglog apache_error.log manage 14 K 19 May 2016 - 00:29 BramVanOosterhout  
Topic revision: r12 - 18 Feb 2017, GeorgeClark - This page was cached on 14 Jan 2020 - 14:16.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy