[SERVLET_SPEC-7] Clarify expected behviour of fitlers and welcome files Created: 25/Aug/11  Updated: 21/Aug/14

Status: In Progress
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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.



 Comments   
Comment by rojkov [ 07/Dec/11 ]

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

Comment by markt_asf [ 07/Dec/11 ]

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.

Comment by Rajiv Mordani [ 28/Jun/12 ]

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.

Comment by Rajiv Mordani [ 09/Jan/13 ]

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.

Comment by markt_asf [ 09/Jan/13 ]

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.





[SERVLET_SPEC-11] Clarification required for ServletContext.getRealPath and HttpServletRequest.getPathTranslated Created: 21/Sep/11  Updated: 21/Aug/14

Status: In Progress
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There appear to be different interpretations of the required behaviour of ServletContext.getRealPath(java.lang.String path) and HttpServletRequest.getPathTranslated() if the virtual path can be mapped to a physical path but the physical path does not exist.

My reading of the specification and the Javadoc is that the physical path does not have to exist, just that the mapping has to be possible. However, I can see how someone else could read the specification as requiring the physical path to exist and null to be returned if it does not.

This should be clarified for Servlet 3.1 and ideally the clarification included in any subsequent maintenance releases of the earlier specification versions.



 Comments   
Comment by gregwilkins [ 23/Sep/11 ]

I think the text should be changed to indicate that a path should be returned if it possibly could exist.

Typically this would mean that if getRealPath("/") returns a non null path, then all calls to getRealPath should not be null.

Comment by Rajiv Mordani [ 28/Jun/12 ]

In section 3.6 of the spec we clearly say

In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. Resources inside the META-INF/resources directory of JAR file must be considered only if the container has unpacked them from their containing JAR file when a call to getRealPath() is made, and in this case MUST return the unpacked location.

and the javadocs also says along the same lines. What do you think will make it clearer?

Comment by markt_asf [ 28/Jun/12 ]

If memory serves me correctly this wasn't a WAR/database/virtual vs local filesystem issue. If was purely in the context of a local file system when everything is unpacked.

Take, for example, a WAR with context path "/foo" unpacked on the local file system to "/usr/local/webapps/foo".

Assume that there also exists the directory "/usr/local/webapps/foo/bar"

When called from the "foo" web application, getRealPath("/bar") will return "/usr/local/webapps/foo/bar".

The question is, what should getRealPath("/other") return?

Should it:
a) return "/usr/local/webapps/foo/other" since that what it maps too?
b) return null since "/usr/local/webapps/foo/other" does not exist?

This really boils down to what does the specification mean by valid in section 3.6? I think we need to make it clear that "valid" does not mean "must exist".

I've dug through the archives and the Tomcat bug that prompted this request for clarification was this one: https://issues.apache.org/bugzilla/show_bug.cgi?id=51799

Comment by Rajiv Mordani [ 29/Jun/12 ]

The getRealPath should return the real paths for resources that are available. So to be specific - in the example above if "other" does not exist in the webapp then it should return null. Looking at the issue filed for tomcat, Remy seems to suggest that it return the path so it is possible to create a file / directory using it. We can discuss this in the EG.





[SERVLET_SPEC-143] HttpServlet.service(ServletRequest,ServletResponse) missing throws text Created: 28/Sep/15  Updated: 28/Sep/15

Status: In Progress
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 minutes
Original Estimate: Not Specified


 Description   

HttpServlet.service(ServletRequest,ServletResponse) has this @throws clause:

@exception ServletException if the HTTP request cannot be handled

But the RI also throws ServletRequestion if either incoming parameter is not an instanceof their Http counterpart.

I think this should be explicitly stated.



 Comments   
Comment by Ed Burns [ 28/Sep/15 ]

M src/main/java/javax/servlet/http/HttpServlet.java

+ * @throws ServletException if the HTTP request cannot
+ * be handled or if either parameter is not
+ * an instance of its respective

{@link HttpServletRequest}

+ * or

{@link HttpServletResponse}

counterparts.

  • @see javax.servlet.Servlet#service
    */
  • Added text to the @throws ServletException of
    HttpServlet.service(HttpServletRequest, HttpServletResponse).
    Sending src/main/java/javax/servlet/http/HttpServlet.java
    Transmitting file data .
    Committed revision 64145.




[SERVLET_SPEC-134] Provide API supporting HTTP/2 Server Push Created: 14/Aug/15  Updated: 30/Oct/15

Status: In Progress
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours, 51 minutes
Original Estimate: Not Specified


 Description   

The most visible user facing feature of HTTP/2 is Server Push. This issue tracks introducing Server Push to the Servlet API.



 Comments   
Comment by Ed Burns [ 14/Aug/15 ]

Doing the work in this branch <https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-134>.





Generated at Tue Sep 27 12:26:48 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.