Topic on Project:Support desk

This may or may not be a bug, but I did notice an issue when mediawiki can be set up to be accessed from server directly as well as from a reverse proxy subdirectory.

Mediawiki - 1.21.1 PHP - 5.3.3 MySQL - 5.1.69 Nginx - 1.4.1

The set up is as follows:

Requests made to https://portal.mydomain.com/subdirectory (handled by a reverse proxy server) makes a backend connection (also over https) to a load balancer (mylb.mydomain.com) on port xxxx, which directs the request to the primary webserver (s1.mydomain.com) or failover webserver (s2.mydomain.com) also on port xxxx.

Mediawiki can be accessed via https://lb.mydomain.com/wiki. Mediawiki config variables: $wgServer = "https://mylb.mydomain.com:xxxx" $wgScriptPath = "/wiki"; $wgArticlePath = "/wiki/$1";

When accessing the wiki from the load balancer URL, everything appears fine. There are no broken links.

From the reverse proxy url https://portal.mydomain.com/subdirectory/wiki, the wiki loads mostly everything. e.g.: https://portal.domain.com/subdirectory/wiki/Main_Page (Returns 200) https://portal.domain.com/subdirectory/wiki/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&* (Returns 200)

However, some of the application is attempting to access the following URL https://portal.mydomain.com/wiki/. Requests made to that subdirectory on the reverse proxy would not be forwarded to our server and thus 404. I see requests these in firebug. e.g.: https://portal.mydomain.com/wiki/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20130625T191716Z https://portal.mydomain.com/wiki/skins/common/images/mediawiki.png

I'm not sure if this is an issue with mediawiki or maybe my configuration.

The reverse proxy should mask the server, and the application should not have to be configured to know the reverse proxy URL. I believe it should be transparent.

Maybe this issue has to do with the nginx URL rewrite to provide short URLS to wiki pages. Here is part of the Nginx configuration:

2. Mediawiki configuration #

location /wiki {

   try_files $uri $uri/ @wiki_rewrite;

}

location @wiki_rewrite {

   rewrite ^/wiki/(.*)$ /wiki/index.php?title=$2&$args;

}

location ~* /wiki/.*\.(js|css|png|jpg|jpeg|gif|ico)$ {

   try_files $uri /wiki/index.php;
   expires max;
   log_not_found off;

}

location = /wiki/_.gif {

   expires max;
   empty_gif;

}

location ^~ /wiki/mw-config/ {

   internal;

}

location ^~ /wiki/(bin|docs|extensions|includes|maintenance|resources|serialized|tests|tools)/ {

   internal;

}

2. PHP FastCGI configuration #

location ~ \.php$ {

   set $fcgi_socket unix:/tmp/fcgi-mediawiki.sock;

   fastcgi_pass $fcgi_socket;
   include fastcgi_params;
   fastcgi_index index.php;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_param SCRIPT_NAME     $fastcgi_script_name;

}

Any ideas?

MediaWiki generates dynamic URLs using JavaScript, and that JavaScript is using wgServer and wgScriptPath, which generates an absolute URL or server-relative URL that the reverse proxy isn't rewritting. This is something a reverse proxy can't handle, and I'd say MediaWiki isn't supported to run under such a reverse proxy.

The simple solution is to avoid to use a junction on the proxy, so no additional subdirectories should be added to each URL. This can be done using a different port or hostname.

For MediaWiki to support a reverse proxy you should open a bug request about that, which should involve the generation of relative URLs in JavaScript instead of absolute URLs, although that may be incompatible with Short Urls.

Thanks for your response.

The reverse proxy configuration can not be changed from this structure of mapping a subdirectory under the https://portal.domain.com/ domain to forward requests to a server on any given port.

I did open a bug request previously as I had thought some kind of url creation was being based off the configuration and not on the requested URL. It seems like there could be a potential fix. I have updated the ticket (https://bugzilla.wikimedia.org/show_bug.cgi?id=52400) with your response.