| Summary: | OSGi Web Container RI: Welcome file in a subdirectory is not invoked | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] Gemini.Web | Reporter: | Violeta Georgieva <milesg78> | ||||||
| Component: | unknown | Assignee: | Glyn Normington <glyn.normington> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | glyn.normington | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 1.1.0.RC1-incubation | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Violeta Georgieva
Created attachment 164691 [details]
sample web application
Thanks for reporting this bug and taking the time to attach a test app. We would like to fix it before too long but we want to do this in Eclipse as we are fairly close to being able to commit the source. I have reproduced this behaviour on both Gemini Web and base Tomcat 6.0.29. Following up with a Tomcat expert. This is working as designed for Tomcat 6.0.x so closing as WONTFIX. From our Tomcat expert... This comes out of an issue with the 2.5 spec. <quote version="2.5" section="SRV.9.10"> "... The Web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a static resource or servlet in the WAR is mapped to that request URI. The Web container must send the request to the first resource in the WAR that matches. ..." </quote> Imagine you have a welcome file list of: index.jsp index.html Noting that the JSP servlet will be mapped to *.jsp, a literal interpretation of the 2.5 spec leads to the following behaviour: - receive partial request - check for partial request/index.jsp static file - none found - check for partial request/index.jsp servlet mapping - *.jsp found - map request to JSP servlet - JSP servlet handles request - no index.jsp file present so JSP sevrlet returns a 404 In short, if you have a JSP in the welcome file list, any entries after it are ignored. As a result, the Tomcat devs elected to require that a physical file must exist for a welcome file mapping to work. You could still use servlet mappings providing you added a zero length file of the appropriate name. So you might see zero length index.do files or similar. The 6.0.x line is not going to change its behaviour in this area. This was 'fixed' in the Servlet 3.0 spec. No-one was overly happy with the result (stuff that worked before might now break) but the spec wording is at least sane. It is: <quote version="3.0" section="10.10"> The Web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a static resource in the WAR is mapped to that request URI. If no match is found, the Web server MUST again append each welcome file in the order specified in the deployment descriptor to the partial request and check if a servlet is mapped to that request URI. The Web container must send the request to the first resource in the WAR that matches. </quote> For further discussion see: https://issues.apache.org/bugzilla/show_bug.cgi?id=47378 You'll see that Hudson breaks on 7.0.x because of the change to the spec. Hi Glyn, May be I didn't explain the issue very well. The use case that you described in your comment is valid, but I think that the use case here is a bit different. The main problem (as I can see it) is in the fact that the redirection from URL http://localhost:8080/WelcomeFiles/test to URL http://localhost:8080/WelcomeFiles/test/ does not happen, as it is expected in the specification. I tried the attached application on pure Tomcat 6.0.29 with unpackWARs="false" and unpackWARs="true" in both cases the URL was redirected correctly and the request was served as expected. The redirection happens in http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_29/java/org/apache/tomcat/util/http/mapper/Mapper.java lines 827-834 When testing on Gemini.Web, the condition on line 827 (Mapper class) is not true and the redirection is not made. I played further with Gemini.Web code and I think I can propose a solution. Please find it attached. Regards Violeta Created attachment 178586 [details]
Solution proposed
Thanks for the clarification and the contribution. Please would you confirm you wrote 100% of the code and have the right to contribute it to Eclipse. (In reply to comment #7) > Thanks for the clarification and the contribution. Please would you confirm you > wrote 100% of the code and have the right to contribute it to Eclipse. I confirm that I wrote 100% of the code and I have the right to contribute it to Eclipse. Regards, Violeta Tested, committed, pushed. Thanks. RC1 is planned instead of milestone 5. |