A short URL is an URL without the xwiki/bin/view parts.

The outbound URL rewriting works only with XWiki 5.2+.
{{/warning}}

Configuring web.xml

You could be tempted to configure the XWiki's web.xml file as follows below but note that the WYSIWYG editor won't work with this solution. The problem is that the /* mapping will override the /*.gwtrpc mapping. This is caused by the Servlet spec which says:

 The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted:
 1. The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet.
 2. The container will recursively try to match the longest path-prefix. This is done by stepping down the path tree a directory at a time, using the '/' character as a path separator. The longest match determines the servlet selected.
 3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last '.' character.
 4. If neither of the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a "default" servlet is defined for the application, it will be used.

In any case if you don't use the WYSIWYG editor this could be a good solution so here it is just in case:

• Copy the mapping for the Struts servlet to also be activated for /*:
    <servlet-mapping>
     <servlet-name>action</servlet-name>
     <url-pattern>/*</url-pattern>
   </servlet-mapping>

  Be sure to leave the other mappings in place, so that /bin/ works, too.

• Configure your container to statically serve /resources/* and /skins/* resources. By default we don't have any mapping for those in web.xml which means they are statically served (by the Default Servlet). Configuring the Default Servlet is container-dependent unfortunately.
  • In Jetty, the container shipped with the XWiki installer, you will have to write:
    • For Jetty <= 6.x:
        <servlet>
         <servlet-name>defaultSkins</servlet-name>
         <servlet-class>org.mortbay.jetty.servlet.DefaultServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
       </servlet>
       <servlet-mapping>
         <servlet-name>defaultSkins</servlet-name>
         <url-pattern>/skins/*</url-pattern>
       </servlet-mapping>
       <servlet-mapping>
         <servlet-name>defaultSkins</servlet-name>
         <url-pattern>/resources/*</url-pattern>
       </servlet-mapping>
    • For Jetty >= 7.x:
        <servlet>
         <servlet-name>defaultSkins</servlet-name>
         <servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
         <load-on-startup>1</load-on-startup>
       </servlet>
       <servlet-mapping>
         <servlet-name>defaultSkins</servlet-name>
         <url-pattern>/skins/*</url-pattern>
       </servlet-mapping>
       <servlet-mapping>
         <servlet-name>defaultSkins</servlet-name>
         <url-pattern>/resources/*</url-pattern>
       </servlet-mapping>
  • In Tomcat, the default Servlet does not accept a parameter for changing the resource base, so you would need to write another default servlet.

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:

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)):

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).

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:

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:

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:

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.