On Fri, 16 Aug 2002, Remy Maucherat wrote: > >>The wording in the 4th paragraph in section 9.10 of the Servlet 2.4 spec > >>may change to: > >> > >> 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 [in the > >> order of 1. a static resource, 2. a servlet that matches > >> exactly, 3. a servlet that matches according to the path > >> mapping rule]. > >> > >>Patrick > > > >
> > Humm... how does this help? > > > > First, note that the "extension mapping" is not mentioned, so things > > like *.jsp, *.boo are not relevant to welcome files. Very good point Bob. The new wording brakes other pieces. > My wish would be that only physical resources can be used as welcome > files, so that the spec is implementable through a native webserver. > (Quite frankly, the use case for the rest is very limited, and very > confusing; plus it would impose a complex wording in the spec - still > not right in that version) +1 My view of the correct behavior ( and others have spent more time with that than me, and they should speak ): - first check for static files. If one is found, that'll do it. That's what the server does - if the file is present. Normal extension mapping will be used on the file. - check for exact or prefix mappings. That will cover precompiled JSPs. - don't check for extension mapping if no physical file is present. There is no way to know if an extension-mapped resource actually exist - so any way you turn it, it can't be used for welcome files without some extra info. The file existence can do that. Keep in mind that extension mapping is a fundamental concept from web servers that was screwed in the servlet spec - no existing server does extension mapping without a physical file. PathInfo is just another victim of 'redefining' and 'extending' a de-facto standard. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>