Comments (10)
- Issue Imported From: https://github.com/javaee/servlet-spec/issues/7
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: @glassfishrobot
from servlet.
@glassfishrobot Commented
Reported by markt_asf
from servlet.
@glassfishrobot Commented
rojkov said:
I am not sure I understand. Can I still a filter request to a welcome file with the proposed change?
from servlet.
@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.
from servlet.
@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.
from servlet.
@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.
from servlet.
@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.
from servlet.
@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-7
from servlet.
@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).
from servlet.
And repeat this recipe for each configured welcome file
from servlet.
Related Issues (20)
- Need new TCK tests for URI Path Canonicalization
- Jakarata : Getting servletcontextlistener exception while migrating the project HOT 3
- Why does this library exist? HOT 2
- Build Requirements JDK8+? HOT 1
- Drop support for server push HOT 11
- Expose zero-copy file transfer in Servlet API
- Generic support for 1xx responses and early hints in particular HOT 2
- Require error dispatches for HTTP requests to always be processed as GET
- Enable HttpSession to be used outside of the scope of an HttpServletRequest
- Add capability of ordering ServletContainerInitializer invocations HOT 45
- Make api clearer for SessionManager.newSession(Request request, String requestedSessionId, Consumer<ManagedSession> consumer) HOT 1
- HttpServletRequest Has method newPushBuilder giving null HOT 2
- HttpServletRequest Has method newPushBuilder giving null HOT 1
- Why is the description about obtaining jakarta.servlet.forward.mapping missing in Chapter 9.3.1 and 9.4.2? HOT 4
- There are a lot of redundant keywords that need to be removed in the jakarta.servlet-api. HOT 1
- Descriptor example in Servlet 6.0 doc is bad HOT 2
- TCK: HttpUpgradeHandler test incorrectly assumes reading of buffered POST data HOT 3
- bad javadoc for sessionIdChanged
- AsyncListener question HOT 1
- Clarify Cookie attribute behavior for empty and null values HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from servlet.