servlet-spec
  1. servlet-spec
  2. SERVLET_SPEC-7

Clarify expected behviour of fitlers and welcome files

    Details

    • Type: Improvement Improvement
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        rojkov added a comment -

        I am not sure I understand. Can I still a filter request to a welcome file with the proposed change?

        Show
        rojkov added a comment - I am not sure I understand. Can I still a filter request to a welcome file with the proposed change?
        Hide
        markt_asf added a comment -

        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.

        Show
        markt_asf added a comment - 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.
        Hide
        Rajiv Mordani added a comment -

        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.

        Show
        Rajiv Mordani added a comment - 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.
        Hide
        Rajiv Mordani added a comment -

        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 <welcome-file-list> 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.

        Show
        Rajiv Mordani added a comment - 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 <welcome-file-list> 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.
        Hide
        markt_asf added a comment -

        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.

        Show
        markt_asf added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            markt_asf
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: