Bug 37424 - welcome-file list not working with extensions
Summary: welcome-file list not working with extensions
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: Unknown
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-09 12:59 UTC by Peter Menzel
Modified: 2006-01-31 06:33 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Menzel 2005-11-09 12:59:28 UTC
When a client requests a partial uri in a webapp with no matching static
resource or servlet/jsp in the DD, Tomcat should process the <welcome-file list>
in the DD and append each <welcome-file> entry to the partial request. After
appending Tomcat should look for a matching static resource or servlet. [1]

Problem as follows:
When using a <welcome-file>foo.bar</welcome-file> and having a servlet matching
the pattern *.bar, this servlet is not invoked.
Using a normal path extension in the welcome file works.

working:
<servlet-mapping>
    <servlet-name>BarServlet</servlet-name>
    <url-pattern>/home</url-pattern>
</servlet-mapping>
<welcome-file-list>
    <welcome-file>home</welcome-file>
</welcome-file-list>

not working:
<servlet-mapping>
    <servlet-name>BarServlet</servlet-name>
    <url-pattern>*.bar</url-pattern>
</servlet-mapping>
<welcome-file-list>
    <welcome-file>foo.bar</welcome-file>
</welcome-file-list>

I know that the deafult servlet maps to <url-pattern>/</url-pattern> so that it
will be invoked before any extension matching servlet, when accessing
http://example.com/mywebapp/ , but when going deeper in the directory structure
the BarServlet should be invoked when accessing e.g.
http://example.com/mywebapp/buzz/ .
The partial request "/buzz/" should be extended by "foo.bar" becoming
"/buzz/foo.bar" and a match with *.bar should invoke BarServlet.

I used Tomcat 5.5.12.

Regards, Peter Menzel

[1] The Servlet spec 2.4 (SRV 9.10) states: "The web server must append each
welcome file in the order specified in the DD to the partial request and check
whether a static resource or servlet in the WAR is mapped to that request URI."
Comment 1 Remy Maucherat 2005-11-09 13:01:53 UTC
That's normal, it can't be implemented.
Comment 2 Peter Menzel 2005-11-09 13:21:59 UTC
So you mean the expressiveness of the Java language is not sufficient to solve
this problem? 

By not implementing this feature, Tomcat does not implement the full Servlet 2.4
spec. So what happens about its status as a reference implementation of this spec. ?

Comment 3 Remy Maucherat 2005-11-09 13:43:51 UTC
(In reply to comment #2)
> By not implementing this feature, Tomcat does not implement the full Servlet 2.4
> spec. So what happens about its status as a reference implementation of this
spec. ?
> 

Another day in BZ, another round of useless statements, another round of
whining. Tomcat IS NOT the "reference implementation of this spec".

This feature is not desirable, and has very bad consequences. As a result, it is
not implemented. If you don't like it, you can either tweak your Tomcat version
or use another implementation of the Servlet specification.
Comment 4 Peter Menzel 2005-11-09 13:57:20 UTC
Oh sorry, I did not know that Tomcat is NOT the official reference implementation.
Obviously I misunderstood the first sentence on http://tomcat.apache.org which
states:
"Apache Tomcat is the servlet container that is used in the official Reference
Implementation for the Java Servlet and JavaServer Pages technologies."
;-)

Can you tell which very bad consequences this feature involves ?

Comment 5 Lilianne E. Blaze 2005-11-09 14:13:59 UTC
not working:
<servlet-mapping>
    <servlet-name>BarServlet</servlet-name>
    <url-pattern>*.bar</url-pattern>
</servlet-mapping>
<welcome-file-list>
    <welcome-file>foo.bar</welcome-file>
</welcome-file-list>

Workaround:

Create empty "foo.bar" file in every directory you need BarServlet to execute.
Comment 6 Remy Maucherat 2005-11-09 14:24:29 UTC
(In reply to comment #4)
> Oh sorry, I did not know that Tomcat is NOT the official reference implementation.
> Obviously I misunderstood the first sentence on http://tomcat.apache.org which
> states:
> "Apache Tomcat is the servlet container that is used in the official Reference
> Implementation for the Java Servlet and JavaServer Pages technologies."
> ;-)

"used" does not mean "used as is".

> Can you tell which very bad consequences this feature involves ?

The (mandatory) default configuration includes "index.jsp" in the welcome file
list, as well as a servlet mapped to "*.jsp". This will not work well at all if
your interpretation of the specification is correct.
Comment 7 Rick Knowles 2005-11-09 14:31:16 UTC
I'd suggest you might get further if you provide an example of a container 
where it is actually implemented as you say. Might be wrong, but I think 
nearly all the container implementations behave the same way as Tomcat (at 
least I can't remember one that acts like you mentioned).
Comment 8 Peter Menzel 2005-11-09 15:06:45 UTC
(In reply to comment #6)
Can you tell which very bad consequences this feature involves ?
> The (mandatory) default configuration includes "index.jsp" in the welcome file
> list, as well as a servlet mapped to "*.jsp". This will not work well at all if
> your interpretation of the specification is correct.

So why should this bear problems? 
When having "index.jsp" in the welcome-file-list and accessing "/buzz/",
"index.jsp" is appended, resulting in "/buzz/index.jsp", which in turn is mapped
to the JspServlet which matches "*.jsp".
When this works, why should the ".bar" extension not?

<servlet-mapping>
    <servlet-name>BarServlet</servlet-name>
    <url-pattern>*.bar</url-pattern>
</servlet-mapping>
<welcome-file-list>
    <welcome-file>foo.bar</welcome-file>
</welcome-file-list>
Comment 9 Lilianne E. Blaze 2005-11-10 02:07:05 UTC
(In reply to comment #8)
> (In reply to comment #6)
> Can you tell which very bad consequences this feature involves ?
> > The (mandatory) default configuration includes "index.jsp" in the welcome file
> > list, as well as a servlet mapped to "*.jsp". This will not work well at all if
> > your interpretation of the specification is correct.
> 
> So why should this bear problems? 
> When having "index.jsp" in the welcome-file-list and accessing "/buzz/",
> "index.jsp" is appended, resulting in "/buzz/index.jsp", which in turn is mapped
> to the JspServlet which matches "*.jsp".
> When this works, why should the ".bar" extension not?

Note it works only if "index.jsp" exists. Same with "foo.bar" - you want it
served, you have to make sure it exists.
Comment 10 Dmitri Colebatch 2005-12-20 02:22:55 UTC
Hi Lilianne, Remy,

I work in what has been a BEA shop for longer than the 3 years I've been here 
and have been been trying to convince management that Tomcat provides a better 
value proposition than WL.  We've just been presented with an opportunity to 
use Tomcat instead of WLX in a new server environment but when migrating apps 
found this bug.

I have a couple of points to make:
1. Whilst the JSP Servlet is only invoked if index.jsp is present I see no 
problem with it being invoked regardless (as it is if you request /index.jsp 
directly).  Either way I'd expect a 404 (although yes I acknowledge other 
welcome file list options might match successfully).
2. WL 8.1 SP3 does implement the spec correctly in this area (in relation to 
comment 7).

Is it unreasonable to request a configuration switch that enables the spec 
behaviour? 
Comment 11 Jan Luehe 2006-01-27 23:51:38 UTC
I don't see where exactly the problem of supporting an extension match for
welcome pages lies.

I've searched both the servlet and jsp specs for references to default
(implicit) welcome pages, but could not find any.

Notice that in the list of welcome pages declared in default-web.xml:

  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
    <welcome-file>index.htm</welcome-file>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>

index.jsp comes last. Also notice this comment in default-web.xml:

  <!-- If you define welcome files in your own application's web.xml      -->
  <!-- deployment descriptor, that list *replaces* the list configured    -->
  <!-- here, so be sure that you include any of the default values that   -->
  <!-- you wish to include.           

Therefore, the welcome pages declared in default-web.xml, and in particular the
index.jsp welcome page, will never interfere with any application-defined
welcome pages.

This means that if a webapp declares its own welcome file list, the index.jsp
welcome file from the default-web.xml, for which an extension mapping always
exists, will not be considered and will not be able to "hijack" any of the
webapp's welcome pages.

I think Mapper.java could be modified as follows: I've moved the existing Rule
4c to 4d, and inserted a new rule 4c that performs the extension mapping. That
failing, Rule 4d is invoked, which checks if the welcome file exists as a
physical resource, and if so, maps it to the default servlet. That still
failing, the next welcome file in the list is checked:

    // Rule 4a -- Welcome resources processing for exact macth
    internalMapExactWrapper(exactWrappers, path, mappingData);

    // Rule 4b -- Welcome resources processing for prefix match
    if (mappingData.wrapper == null) {
        internalMapWildcardWrapper
            (wildcardWrappers, context.nesting, 
             path, mappingData);
    }

    // Rule 4c -- Welcome resources extension match
    if (mappingData.wrapper == null) {
        internalMapExtensionWrapper(extensionWrappers,
                                    path, mappingData);
    }

    // Rule 4d -- Welcome resources processing
    //            for physical folder
    if (mappingData.wrapper == null
            && context.resources != null) {
        Object file = null;
        String pathStr = path.toString();
        try {
            file = context.resources.lookup(pathStr);
        } catch(NamingException nex) {
            // Swallow not found, since this is normal
        }
        if (file != null && !(file instanceof DirContext)
                && context.defaultWrapper != null) {
            mappingData.wrapper = context.defaultWrapper.object;
            mappingData.requestPath.setChars
                (path.getBuffer(), path.getStart(), 
                 path.getLength());
            mappingData.wrapperPath.setChars
                (path.getBuffer(), path.getStart(), 
                 path.getLength());
            mappingData.requestPath.setString(pathStr);
            mappingData.wrapperPath.setString(pathStr);
        }
    }

Please let me know what you think and if you want me to supply any diffs.

I don't think we need any configuration switch for this feature: It should be
supported by default if approved.

Jan
Comment 12 Jan Luehe 2006-01-30 21:31:43 UTC
I agree that if you do not override the welcome-file-list from default-web.xml
(by providing your own welcome-file-list in your web.xml), dir listings will
always be disabled (since index.jsp will always be mapped to JspServlet), and
the JspServlet will return a 404 if index.jsp does not exist.

But this goes back to my original question: I searched again, and could not find
any reference in the Servlet or JSP specs about a list of built-in welcome pages
a container must support. If a webapp relied on the welcome-file-list in
default-web.xml, it would be non-portable.

So in order to support extension mappings for welcome pages, we need to remove
index.jsp from the welcome-file-list in default-web.xml.
Comment 13 Remy Maucherat 2006-01-30 22:43:22 UTC
(In reply to comment #12)
> I agree that if you do not override the welcome-file-list from default-web.xml
> (by providing your own welcome-file-list in your web.xml), dir listings will
> always be disabled (since index.jsp will always be mapped to JspServlet), and
> the JspServlet will return a 404 if index.jsp does not exist.

I understand you have an interest in forcing Tomcat into supporting nonsensical
specification features, as your own server has to do. This project fortunately
does not have to do that anymore. In a way, this is the role of the RI: finiding
out what really doesn't make sense when comes the time of implementing
something. Personally, I think you need to make more useful contributions to
this project rather than attempt to fix non issues that bother everyone else,
including:
- the getId stuff
- the charset encoding nonsense
- and now, this one
Comment 14 Jan Luehe 2006-01-30 23:31:38 UTC
Here's an additional requirement from the servlet spec that can be
supported only if extension mappings were applied to welcome pages in
the same fashion as they are for any other types of resources:

SRV.9.10 ("Welcome Files") has this:

  The container may send the request to the welcome page resource with a
  forward, a redirect, or a container specific mechanism that is
  indistinguishable from a direct request.

For a server than sends a request to a welcome page using a redirect,
it will be impossible to later determine whether the target resource is
being accessed directly or as the result of the redirect, and suppress
or perform extension mappings accordingly.

Comment 15 Jan Luehe 2006-01-30 23:49:14 UTC
In response to Comment#13:

Please notice that the extension mapping for welcome pages issue was
not initially raised by me. It was first reported by
petermenzel@gmx.de, and I only jumped on it recently because this very
issue has been raised by others. Considering the number of replies on
this thread, I would not consider this a "non-issue".

I agree if the Servlet or JSP specs required support for a built-in
welcome page "index.jsp" (as you implied in one of your comments), the
specs would have an issue. But fortunately, neither spec requires
this.

I just read your email to the EG. I hope this issue can be clarified
to everybody's satisfaction.

I'm not sure what you mean by the "getId stuff". Are you referring to
the new method that was added to javax.servlet.jsp.tagext.TagSupport?
If so, please check with the JSF and JSP expert groups for the motivation
behind this new method.

The "charset encoding nonsense" has been the result of alignment work
between the JSP and Servlet EGs. It was not suggested by me.
Comment 16 Remy Maucherat 2006-01-31 00:36:30 UTC
I have problems with Tomcat only getting the annoyances and no useful
contributions at all. I do not find that acceptable. Hopefully you understand
what I mean.

Indeed, I did just send an email to the expert group in an attempt to resolve
some points of the specification which do not make any sense in the real world.
I expect to be ignored.

(about the getId stuff, I mean HttpSession.getId throwing an ISE for no reason)
Comment 17 Jan Luehe 2006-01-31 02:33:40 UTC
Hi Remy,

I'm not pointing fingers at Tomcat at all. Look at it this way: I am just trying
to help resolve a customer issue, so I hope you find this a somewhat useful
contribution. ;-)

As for HttpSession.getId() throwing an ISE on an invalidated session, I agree
this is useless and requires all kinds of workarounds, but I claim innocence on
this as well.

This issue has a long history: Apparently, getId() and getLastAccessedTime()
were always supposed to throw this exception, but there used to be a typo in the
tag name ("@exeption" instead of "@exception") in the HttpSession.java source
file, which meant the exception was never reflected in the javadocs.
Unfortunately, the EG decided to "fix" this in the 2.4 Errata. I with they had
taken this as a hint and removed this exception, at least in the case of
getId(). You have my support on this! :)

I will reply separately to your email that you just sent to the EG.
Comment 18 william.barker 2006-01-31 08:49:24 UTC
I'm going to have to vote with Remy on this one.  As Remy has pointed out, 
Tomcat isn't the RI any more so supporting silly and (as writen in the 2.4 
spec) unclear requirements in Tomcat isn't really an issue.  And, in any case 
there is a simple, one-line way to get this working under Tomcat (just create 
an empty 'index.do' file under all subdirectories).

+1 for leaving as WONTFIX.
Comment 19 Remy Maucherat 2006-01-31 10:46:39 UTC
(In reply to comment #17)
> Hi Remy,
> 
> I'm not pointing fingers at Tomcat at all. Look at it this way: I am just trying
> to help resolve a customer issue, so I hope you find this a somewhat useful
> contribution. ;-)
> 
> As for HttpSession.getId() throwing an ISE on an invalidated session, I agree
> this is useless and requires all kinds of workarounds, but I claim innocence on
> this as well.

Guess what: I got some customer issues too about the getId stuff :) So after
trying it out, I now think this sort of fix is actually negative, and impacts
production usage.

I don't know from where the default welcome file list comes from (for some
reason, I cannot find it anymore). It has always been there like it is now, I think.
Comment 20 Tim Funk 2006-01-31 13:15:17 UTC
+1 on Bill's -1. 

It will be very painful for users if they change their welcome file order to
make *.jsp a higher precendence than index.html. Doing so will NEVER allow a
user to serve an html file as a welcome file with the proposed change. That is
horrible usability. [I don't even want to touch the topic of the struts folks
with the index.do mapping]

The servlet spec's notion of mapping is full of holes. An example: when asking
for a RequestDispatcher for a non-existant resource - a RequestDispatcher is
still returned. And if the RequesDispatcher is executed - a 404 or ISE occurs
(depending on how and when it was executed). This is confusing from a developer
point of view due to the mappings of the default servlet. 

Comment 21 Peter Rossbach 2006-01-31 14:08:38 UTC
Currently the SingleSignOn Valve not working anymore with the getLastAccessTime() ISE!
    s. user mailing thread last week.

I thing we can implement that a "*.do" mapping can handle by welcome file directly. The
idea to generate index.do files is not very acceptable to end user. 
Comment 22 Remy Maucherat 2006-01-31 14:35:04 UTC
(In reply to comment #21)
> Currently the SingleSignOn Valve not working anymore with the
getLastAccessTime() ISE!
>     s. user mailing thread last week.
> 
> I thing we can implement that a "*.do" mapping can handle by welcome file
directly. The
> idea to generate index.do files is not very acceptable to end user. 

For the first part, this is OT, but session events should be sent while the
session is still considered valid (I was talking about session attributes
implementing the binding listener interface, and most of these are using getId -
for example, our own example/test webapps were). Please post a reference to the
post.

Note: Can you make an effort with your English ?
Comment 23 Peter Rossbach 2006-01-31 15:33:11 UTC
Here is the missing discussion link:
http://marc.theaimsgroup.com/?l=tomcat-dev&w=2&r=1&s=llegalstate+during+invalidate+delta&q=b