Last modified: 2014-06-23 16:06:55 UTC
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. 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), which directs the request to the primary webserver (s1.mydomain.com) or failover webserver (s2.mydomain.com). Mediawiki can be accessed via https://lb.mydomain.com/wiki. Mediawiki config variables: $wgServer = "https://mylb.mydomain.com" $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. I believe I could change the mediawiki variables to: $wgServer = "https://portal.mydomain.com" $wgScriptPath = "/subdirectory/wiki"; $wgArticlePath = "/subdirectory/wiki/$1"; but then I am pretty sure attempting to access it via the load balancer directly would not work properly. 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.
Did you ask on https://www.mediawiki.org/wiki/Project:Support_desk already?
https://www.mediawiki.org/wiki/Project:Support_desk#Mediawiki_running_behind_loadbalancer_and_reverse_proxy.2C_Some_links_are_breaking._31588
Yes, I did post this on the Project:Support Desk per your recommendation. Ciencia Al Poder replied stating: <blockquote>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.</blockquote> https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Mediawiki_running_behind_loadbalancer_and_reverse_proxy,_Some_links_are_breaking./reply It seems that mediawiki does not have the capability of being run behind a reverse proxy in this mannor. It does have the short URLs working from the load balancer directoy as well as from behind the reverse proxy. It seems that links that are broken may come from the relative URLS generated in JavaScript which are not aware they are behind the reverse proxy and using an absolute URL. Allowing for this feature seems possible.