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]>

Reply via email to