Mark I went back and looked at the discussion in the 3.0 and am including some of that here -
My colleague Shing Wai Chan pointed out that the proposed solution is
somewhat unsatisfactory in the sense that it still might be possible
to receive a 404 response when honoring one welcome page even if the
next welcome page in the list would have produced a valid result.
Consider a slight variation of Greg's original example, where
"index.html" is replaced with "foo.bar" in the list of welcome page
Further assume that:
- a servlet mapping (to the "FooBar" servlet) exists for "*.bar",
- neither index.jsp nor foo.bar exist as file resources, and
- the FooBar servlet does not depend on foo.bar in order to produce
The proposed new algorithm would not find any matching static
resources when enumerating the welcome page declarations during the
first round, but would honor the servlet mapping for index.jsp when
enumerating the welcome page declarations in the 2nd round, leading to
a 404, even if skipping "index.jsp" and picking "foo.bar" instead
would have produced a valid response.
I guess there is nothing we can do to help in this case. It would be
nice if it were possible to specify (in a welcome declaration) whether
the welcome page needs to exist as an actual file resource in order
for its mapped-to servlet to be able to produce a response, but the
current syntax for <welcome-file-list> would make this hard if not
and Greg's response to that was -
I think this is indeed a problem, but I don't think there is much we can
do to fix it without changing the web.xml.
There is a fundamental problem of mixing the search semantics that
can be done on files with dispatching to servlets, which don't
support search semantics.
I think that the current compromise is the best we can do if we
wish to continue allow servlets to be welcome-files even when
the no file exists.
Given that even appending the files may not work, I think we can't really fix it the way you are suggesting.