A directory request (
http://<hostName>/, for example) is an ambiguous request.
You're not really saying what resource you want.
You're expecting some component on the server side to decide what will actually be served.
The issue is that you have 2 components on the server side:
And both are capable of serving things.
- The webserver (IIS, iPlanet, or Apache)
The webserver's notion of a file-list is often referred to as "default pages" (defined in the webserver itself).
ServletExec's notion of a file-list is often referred to as "welcome files" (defined in a webapp).
For any given request, only 1 or the other file-lists can be used (either "default pages" or "welcome files").
This is because only 1 or the other components (webserver or SE) will actually get to process the request by building the response. So the file-list ("default pages" or "welcome files") should only contain resources that the component defining it can actually process.
For example (using an ASP page as an EXAMPLE):
You can't list index.asp as a welcome file in a webapp since a webapp (running inside a servlet container such as ServletExec) can't process an ASP page (at least not without you adding that ability to that webapp). And the same logic is true for the reverse... you can't put index.jsp as a default page in IIS since IIS can't process a JSP.
To better understand this whole issue, you must understand which component is trying to build the response for your request.
There are a few factors involved in this decision.
Consider a webapp that is deployed in SE 5.x (or higher).
When a request comes to that webapp, SE must decide "is this a request for static content, or is it for dynamic content?".
This is decided by checking the aliases defined in the webapp against the request URI to see if the request matches any aliases (prefix, exact, or suffix aliases) that map to anything in the webapp (map to a servlet, or a filter, or a security constraint)... anything that would mandate that SE be the one to "service" the request by performing some action (typically by building a response). Another criteria for deciding that the request is for dynamic content is whether or not the request is a directory request and whether or not the webapp defines ANY welcome files.
If a directory request comes to a webapp that DOES define 1 or more welcome files then that is deemed a request for "dynamic" content, and SE will be the component that will build the response for that request.
If a directory request comes to a webapp that does NOT define any welcome files (and does not have a default alias mapping such as
/* then that is deemed a request for "static" content.
If that webapp were set to let SE serve static content then the webapp will return 404-Not Found (since there are no welcome files defined in that webapp).
If that webapp were set to let the webserver serve static content then SE will hand the request back to the webserver and let the webserver try to service it. It makes no sense to try to have the webserver serve a JSP.
You may also need to understand the webapp named "default-app" which has special properties. It's a webapp that's deployed with every new SE 5.x (or higher) installation by default, and it is unlike other, "normal" webapps in the sense that it does NOT use it's own private document root that's separate from the document root of the webserver the way other, "normal" webapps do. Instead the default-app will use the document root of the webserver as it's own document root. Note that with SE AS, this would be the value of the -root option in the Start Script for the AS Instance [ASI]. If that value is edited from it's default, or if the ASI is on a separate machine from the webserver, then it may not truly be the webserver's document root. But it is still the place that is used as the document root of the default-app.
This is what allows someone to drop index.jsp into a webserver's document root (or whatever folder you are using as your -root), request it, and have it be found, and executed/served properly. In that scenario, the person may not even realize that their request actually executed within the context of the webapp named "default-app". This is an important distinction from other webapps because it effects where you should place your content (html files, images, etc...) The context (i.e. the webapp) to which a request maps (based on the context path in the request URI) and what that webapp uses as it's document root, matters.
One way to resolve this is to define ALL your default-pages/welcome-files using the file-list of your webapp running inside of SE (that is... don't use your webserver's file-list at all).
Here is the flow for doing that:
You'd define ALL your welcome files inside your webappp, even something such as index.asp, instead of using the webserver's file-list. Now if you just stop there, then SE would end up serving the source of index.asp as-is (i.e. not actually processed as you want). So don't stop there, have that index.asp be a "dummy" version, that just contains a redirect to the real index.asp... only the real index.asp is called something else like index.aspx. This way a request for
http://<hostName>/<webappContextPath>/index.aspx (or index2.asp, or whatever... just a file by some other name or in some other location within the webapp).
You still can't stop there though... you must also configure your webapp so that it lets the webserver serve static content.
This way when the webapp receives the redirected request for
http://<hostName>/<webappContextPath>/index.aspx and deems it to be a request for "static" content, SE will tell the webserver to serve it, and the webserver (presumably IIS for this example) will know how to process index.aspx properly.
Or you could try to obtain a Servlet capable of actually processing the ASP (or whatever resource you're wanting to be served), configure it in your webapp, and then map
*.asp to that servlet so that then your webapp actually could process that resource properly (no need to redirect).
Readers of this FAQ may also benefit from reading SE FAQ #324