tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Sandberg...@cs.stanford.edu>
Subject Re: http 302 issue on tomcat 4.0.1
Date Tue, 04 Jun 2002 22:58:06 GMT
The spec says that for each welcome file you must check 'whether a 
resource 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. '  

This is somewhat ambiguous--do they mean resource like getResource(...) 
or do you mean a mapping in the deployment descriptor.  Given the 
example you mentioned, it seems they probably mean resource like 
getResource(...).

If this is true, then bug 9016 is actually by design...

[PROPOSAL] We could do the following, which might be a good compromise 
between the two possible interpretations:

If there is one welcome-file, then always redirect to it.  If there is 
no corresponding resource, then this could give us a 404 ( if it is a 
JSP ) or work properly ( if it is a *.do ).  Happily this does not 
violate the spec, because the spec says that if no resource if found, 
the container can do whatever it wants anyway.

If there is more than one welcome-file, then we do need to check for 
corresponding resources.  If none are found, we probably give a 404, right?

This is a little ugly since one wouldn't expect the behavior to change 
when adding a welcome-file, but it might be the best solution.

Thoughts?  I'm slightly leaning towards saying the behavior in bug 9016 
is spec-mandated.

As for the speed issue, I would be happy to address it with caches or 
something else ( I love optimizing ) when someone gave me very 
conclusive proof that the mapping overhead is significant.

-Dan


Remy Maucherat wrote:

>>if matchingWelcomeFile.contains("/"):
>>  # psycopathic case no one cares about ( ie. welcome file is a/b.jsp )
>>  redirect, old style //we show the filename here, but if we didn't we'd
>>break relative paths
>>else:
>>  if path.endsWith("/"):
>>    # happy, smiley family case
>>    redispatch, using welcome-file full path (ie. /foo/index.jsp ) for
>>security checking
>>    
>>
>
>This redirect may cause problems, because it will happen regardless of
>whether or not the path exist (or it makes sense to redirect).
>
>Example:
>You have index.jsp and index.html in the welcome files. No matter what you
>do,
>the request will always be redirected to Jasper, which will always return a
>404. Checking for the presence of the physical file won't work either
>(you could have a *.do mapping like Struts uses).
>
>Any idea to avoid that problem ?
>
>Also, the changes are going to make the mapping slower. I plan to refactor
>that
>operation (use an automaton and bytes instead of String manipulations) in
>the
>next major version of Tomcat, which should help tremendously, but until
>then ...
>
>  
>
>>  else:
>>    if adding slash causes a servlet mapping match:
>>      # we handle the stupid case of having two servlet mappings
>>      # ( /foo and /foo/ ) in web.xml.
>>      redirect, old style //we show the filename here, but if we didn't
>>we'd call the wrong servlet
>>    else:
>>      redirect, adding "/" ( ie. redirect /foo to /foo/ )
>>    
>>
>
>Remy
>
>
>--
>To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
>
>
>  
>




--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message