Clarify expected behviour of fitlers and welcome files

[glassfishrobot]

The specification is not explicit regarding the order of welcome file processing and filter mapping. This has caused limited user confusion.

My own expectation is that welcome files are processed first and then filter mappings. Previous conversations with Servlet 3.0 EG members confirmed this. It would be help to get a short note of this added to the Servlet 3.1 spec.

[glassfishrobot]

@glassfishrobot Commented
Reported by markt_asf

[glassfishrobot]

@glassfishrobot Commented
rojkov said:
I am not sure I understand. Can I still a filter request to a welcome file with the proposed change?

[glassfishrobot]

@glassfishrobot Commented
markt_asf said:
OK. Here is some additional clarification.

If a user requests "/foo" and "/foo" is a directory, the welcome files "index.jsp" and "index.html" are configured and "index.html" is present then what is compared against the filter mappings. Is it "/foo" or "/foo/index.html"

The clarification I previously received from the Servlet 3.0 EG is that is is "/foo/index.html" that is compared against the filter mappings. It is this clarification I would like to see in the 3.1 spec.

[glassfishrobot]

@glassfishrobot Commented
mode said:
Sounds reasonable to me - one question is what happens in the case of the DefaultServlet being invoked in the case where we don't have a welcome file? Should it then be that the filter is applied to /foo or not? I will start a thread on this in the EG.

[glassfishrobot]

@glassfishrobot Commented
mode said:
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
declarations:

index.jsp
foo.bar

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
  its response

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 would make this hard if not
impossible.

Comments?

Jan

and Greg's response to that was -

Jan,

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.

[glassfishrobot]

@glassfishrobot Commented
markt_asf said:
I think in the case of the default servlet returning a 404 then the filter should be applied if url-pattern matches whatever url the default servlet is returning a 404 for.

Regarding the the issues described in the extract of the Servlet 3.0 discussion I think that is a slightly different issue. In Tomcat we introduced a list of "resource only servlets" which essentially only get mapped to welcome files if a file resource (e.g. a JSP) exists at that URL. I do wonder if that container specific solution could be generalised (e.g by a new attribute on Servlet) but that is a discussion for a different issue / the mailing list.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-7

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/servlet-spec/issues/7
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[manorrock]

@gregw As the default Servlet is a special case (implicitly configured) I feel it should not be part in the welcome file processing. In my mind the welcome file processing should a) look to see if the file is available within the web application if so use it, or b) look to see if there is an exact filter / servlet mapping done for the given request and if so use it, or c) see if an extension filter / servlet mapping is done and use it, or d) see if a prefix filter / servlet mapping is done and use it (excluding the default servlet here).

[manorrock]

And repeat this recipe for each configured welcome file