Short XWiki URLs
This tutorial shows you how to tune your XWiki platform by replacing the default URL scheme with a shorter scheme.
I. Application name
The /xwiki/ part of the URL is the application name. It identifies the application that should process the request, and it allows a container to host more than one application. To change it you must refer to your container's documentation and find how to map the context path of a web application. For example on Tomcat it's enough to simply deploy the XWiki webapp in the webapps directory, in a sub directory named after the application name you wish to use (e.g. webapps/myappname).
A special case is when deploying XWiki as the ROOT application, which actually allows the application name part to be empty, so an URL can take the form server.com/bin/view/Space/Document. Achieving this depends on the container, as there's no standard regarding the ROOT application. For example:
- in Tomcat, with the default configuration, all it takes is to deploy the XWiki web application in webapps, in a sub directory named ROOT (i.e. webapps/ROOT).
- In Jetty, with the default configuration, all it takes is to deploy the XWiki web application in webapps, in a sub directory named root. Note that if you're using the Standalone distribution (which packages Jetty and HSQLDB) then you'll also need to:
- Remove the existing webapps/root directory which contains a redirect Servlet that automatically redirects root URLs to the xwiki context. You won't need that anymore.
- Rename the existing webapps/xwiki directory into webapps/root.
- Remove the jetty/contexts/xwiki.xml file and thus keep only the jetty/contexts/root.xml file. Otherwise you'll get a warning in the console.
Refer to your container's documentation for more details.
II. Servlet mapping name
The second part is the hardest part to remove. It identifies the servlet that should process the page, which, for /bin/, is the Struts servlet. Generically speaking, to get rid of /bin/, you need to configure your system so that URLs matching /* are mapped to the Struts Servlet (by default only /bin/* URLs are mapped to the Struts Servlet).
However you need to be careful that the following prefixes do NOT go through the Struts Servlet (see your web.xml to check their current mappings):
- /resources/* and /skins/*: Statically served resources. These need to be served directly as static resources.
- /rest/*: REST resources, served by the XWiki REST Servlet
- /xmlrpc/*: XML-RPC resources, served by the XWiki XMLRPC Servlet
- /resources/**/*.gwtrpc: GWT-RPC calls, served by the XWiki GWT Servlet
- /webdav/*: WebDav calls, served by the XWiki WebDAV Servlet
- /XWikiService: Another XWiki GWT Servlet
- /redirect: The XWiki Redirect Servlet used to redirect to the home page when no page is specified in the URL
There are various alternate to achieve this:
XWiki also generates URL and you can tell it to generate URLs without the bin/ part by adding this piece of code in xwiki.cfg: xwiki.defaultservletpath= (Note that this is not required with the UrlRewriteFilter solution described below since it rewrites outbound URLs too).
UrlRewriteFilter
"UrlRewriteFilter" is a framework offering a Servlet Filter allowing to rewrite URLs.
Install steps:
- Download the JAR and put it in WEB-INF/lib
- Edit your WEB-INF/web.xml and add the <filter> and filter-mapping definitions as documented
- Drop the following content in a file at WEB-INF/urlrewrite.xml:<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN"
"http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite>
<rule>
<note>
Ensure that URLs ending with .gwtrpc are not modified.
</note>
<from>^/(.*)\.gwtrpc$</from>
<to type="forward" last="true">-</to>
</rule>
<rule>
<note>
En sure that URLs that must not be served by the Struts Servlet are not modified.
</note>
<from>^/(bin|resources|skins|rest|webdav|xmlrpc)/(.*)$</from>
<to type="forward" last="true">-</to>
</rule>
<rule>
<note>
For all other URLs we prepend the "/bin/" prefix so that they get routed to the XWiki Action Servlet.
</note>
<from>^/(.*)$</from>
<to type="forward">/bin/$1</to>
</rule>
<outbound-rule>
<note>
Rewrite outbound URLs to remove the "/bin" part.
</note>
<from>/bin/(.*)/(.*)$</from>
<to>/$1/$2</to>
</outbound-rule>
</urlrewrite>
web.xml + Apache
Do as above but instead of mapping the Default Servlet, bypass the Servlet container at the web front-end level. For example, if you are using Apache httpd as a front-end, and assuming a webapp deployed as a ROOT webapp and an AJP connection between httpd and the servlet container, the following configuration allows you to serve skin files and static resources directly from httpd:
Alias /resources /usr/local/xwiki/resources
ProxyPass /skins/ !
ProxyPass /resources/ !
Note that this solution will not work for the WYSIWYG editor since it needs that the .gwtrpc URLs are directed to the XWiki Servlet. The following Apache configuration using URL rewriting achieves this:
Alias /resources /usr/local/xwiki/resources
RewriteEngine on
RewriteRule ^/+skins - [L]
RewriteCond %{REQUEST_URI} !\.gwtrpc$
RewriteRule ^/+resources($|/.*) - [L]
RewriteRule .* http://localhost:8080%{REQUEST_URI} [P,L]
ProxyPassReverse / http://localhost:8080/
Lighttpd + Jetty
I used lighttpd, but I assume it can be done with other webservers too. This is the configuration I used in the lighttpd config (note that my xwiki folder has been moved to /usr/share/jetty/webapps/root (no 'xwiki' at all)):
# ensure all requests for .gwtrpc files go through to java server
# we can put this rule first as a higher priority, which java couldn't do
$HTTP["url"] =~ "\.gwtrpc$" {
proxy.server = ( "" => (( "host" => "127.0.0.1", "port" => 8080 )))
}
# otherwise, we can handle the static resources
else $HTTP["url"] =~ "^/resources/" {
alias.url += ( "/resources" => "/usr/share/jetty/webapps/root/resources" )
}
# otherwise, we can handle the static resources
else $HTTP["url"] =~ "^/skins/" {
alias.url += ( "/skins" => "/usr/share/jetty/webapps/root/skins" )
}
# and here is the primary server
else $HTTP["host"] =~ "^www\.domain\.com$" {
proxy.server = ( "" => (( "host" => "127.0.0.1", "port" => 8080 )))
}
}
# redirect anything.domain.com to www.domain.com
else $HTTP["host"] =~ "\.domain\.com$" {
url.redirect = ( "^/(.*)" => "http://www.domain.com/$1" )
server.name = "www.domain.com"
}
# redirect domain.com to www.domain.com
else $HTTP["host"] =~ "domain\.com$" {
url.redirect = ( "^/(.*)" => "http://www.domain.com/$1" )
server.name = "www.domain.com"
}
So lighttpd will serve any static content unless it has .gwtrpc on the end of the URL.
If you use Nginx as a web-server, just add three more locations and set root to them. By try_files Nginx checks static content presence and if doesn't exist, redirect it to the Tomcat (we expect dynamic content in this case, including all *.gwtrpc requests).
root /var/lib/tomcat7/webapps/ROOT;
}
location /resources/ {
try_files $uri $uri/ @fallback;
root /var/lib/tomcat7/webapps/ROOT;
}
location @fallback {
proxy_pass http://localhost:8080;
}
In the example above XWiki installed as ROOT application in Tomcat. Change path to your XWiki application accordingly.
Then in web.xml, I changed the gwtrpc mapping to:
<servlet-name>gwtrpc</servlet-name>
<url-pattern>/resources/*</url-pattern>
<url-pattern>/skins/*</url-pattern>
</servlet-mapping>
Since we are using a url-pattern of /path/, it will be specific enough to be a higher priority than the / pattern we'll use next. And since the only thing that will come through via resources or skins will be gwtrpc, then we can be sure it's ok. Note that only resources is required, but I did both anyway.
Now, as described above, add a rule to catch everything else and redirect it to your XWiki servlet:
<servlet-name>action</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
III. Struts action name
The third part, /view/, identifies the struts action that should process a request. So this tells what we want to do with the document, /view/ it, /edit/ it or /delete/ it, for example. The XWiki platform allows this part to be missing, considering that the default action is to just display the document, so an URL like server.com/bin/Space/Document will work out of the box.
Even more, the URL factory, the component that generates URLs, can be configured to skip this part when the action is /view/. To do this write this code in xwiki.cfg: xwiki.showviewaction=0.
IV. Error Page
At the WEB-INF/web.xml, the location of the 404 error code needs to be changed accordingly. For example:
<error-code>404</error-code>
<!--<location>/xwiki/bin/view/Main/DocumentDoesNotExist</location>-->
<location>/bin/Main/DocumentDoesNotExist</location>
</error-page>
V. Conclusion
After performing all these changes, you should be able to access documents with URLs like:
- server.com/Space/Document
- server.com/Space/ (pointing to Space.WebHome)
- server.com/Document (pointing to Main.Document)
- server.com/ will show Main.WebHome, without any redirect.
As a bonus, these changes are backwards compatible, meaning that any currently working URL will also work with these changes performed, so you won't have any broken bookmarks.
