ServletPath and PathInfo: servlet API weirdness

I'm playing with servlets these days, out of the Cocoon environment, and have been caught by a very strange behaviour, that is actually clearly stated in the servlet specification.

Let's consider this servlet mapping in web.xml that defines "App" as the default servlet:

 <servlet-mapping>
 <servlet-name>App</servlet-name>
 <url-pattern>/</url-pattern>
 </servlet-mapping>

Now call http://server/context/path/to/test.html. Here are the request properties:

getPathInfo() : null
getServletPath() : "/path/to/test.html"

Why is path info null, and why does the servlet path have what we could have expected to see in path info?

Let's change web.xml like this, so that "App" eats the same URLs but is no more the default servlet:

 <servlet-mapping>
 <servlet-name>App</servlet-name>
 <url-pattern>/*</url-pattern>
 </servlet-mapping>

And call again the same http://server/context/path/to/test.html:

getPathInfo() : "/path/to/test.html"
getServletPath() : "" (empty string)

WTF?!?! Is it a bug in the servlet engine? Let's check the servlet specification...

In the "Mapping request to servlets" chapter, the specification of mappings is described:

A string beginning with a ‘/’ character and ending with a ‘/*’ postfix is used for path mapping.
A string beginning with a‘*.’ prefix is used as an extension mapping.
A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
All other strings are used for exact matches only.

When writing the "/" mapping, we use rule 3, whereas when using the "/*" mapping, we use rule 1.

So that means that a servlet that needs to map a resource according to the request URL must behave differently depending on whether it is defined as the default servlet or mounted to a particular location. What's the reason for this???

Good old Cocoon fixes this by simply concatenating the path info and servlet path, so that your application doesn't have to care about it.

Hmm... I'm going to write a "ConsiderTheDefaultServletAsAnyOtherServlet" request filter that will do the same...