/ vs /* servlet URL mapping

[Raf Szczypiorski]

As in the topic - what is the semantic difference between these two mappings? I fail to see any, but I am most likely wrong about that.

[Ulf Dittmer]

"/" only maps to the root http://www.server.com/ but not to any sub-URLs such as http://www.server.com/whatever - which "/*" does.

[Raf Szczypiorski]

I am not sure if this is correct. Here:
http://www2.roguewave.com/support/docs/leif/leif/html/bobcatug/7-3.html
under 7.3.3. says:
A mapping that contains the pattern <url-pattern>/</url-patttern> matches a request if no other pattern matches.

Additionally, servlet 3.0 specs say (12.2, Specification of mappings):
The empty string ("") is a special URL pattern that exactly maps to the
application's context root, i.e., requests of the form http://host:port/<context-
root>/. In this case the path info is ’/’ and the servlet path and context path is
empty string ("").
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.

So, what you said about '/' mapping seems to be incorrect, and it is an empty '' mapping. Please correct me if I am wrong.


What I don't understand is this: I have a '/*' mapping, which catches all. If I have the default servlet '/' which is invoked when no other mapping matched, it is invoked - so it is also a catch-all. What is the difference between the two?

[Raf Szczypiorski]

Aah - the difference seems to be in the servletPath: for '/' the servlet path is everyhing after the context path, whereas for '/*' is an empty string.
This is quite confusing.

[T Jung]

Have you tried something like:
http://www.server.com/whatever/filedoesnotexist.jsp
in case of <url-pattern>/</url-pattern> you receive a 404 not found message
in case of <url-pattern>/*</url-pattern> it matches

[Raf Szczypiorski]

Ok, but here you are using implicit *.jsp mapping, not the default servlet, and as the file does't exist, you get 404.
Also, that you get something from your (presumably) Tomcat doesn't mean that it is valid according to the specification, it might be a 'custom' bug.