tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 4597] - webdav fails in update, delete or copy operations on jsp files
Date Mon, 05 Nov 2001 12:31:56 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4597>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4597

webdav fails in update, delete or copy operations on jsp files





------- Additional Comments From wtff@freenet.de  2001-11-05 04:31 -------
Thanks for your detailed answer. I must say, you guys are really quick and 
diligent! The answer helps me a lot.
Nonetheless, I would like to submit one further comment, to oppose the 
argument, that the behaviour of tomcat/webdav is correct:

According to the Servlet Specification 2.3, chapter SRV11.1 and SRV11.2, a URL 
is mapped to an appropriate handler component by trying several matches in a 
predefined order:
1st: trying an exact URL match
2nd: longest path match
3rd: suffix match
    (here, a .jsp path gets matched, ONLY, if no servlet is matched to a path 
prefix!)
4th: usual static content, unless a default servlet has been specified.

Also, in order to wipe out any further misunderstanding concering in how far  
containers may overwrite this behaviour, let me paste the following short 
passage from the spec, that explicitly states that a servlet/jsp container 
(like tomcat) is not allowed to give its .jsp mappings precedence over servlet 
mappings defined by webapps (like the webdav servlet mapping):

SRV.11.2.1 Implicit Mappings
If the container has an internal JSP container, the *.jsp extension is mapped 
to it,
allowing JSP pages to be executed on demand. This mapping is termed an implicit
mapping. If a *.jsp mapping is defined by the web application, its mapping takes
precedence over the implicit mapping.
A servlet container is allowed to make other implicit mappings as long as
explicit mappings take precedence. For example, an implicit mapping of
*.shtml could be mapped to include functionality on the server.


----

The important phrase is: "A servlet container is allowed to make other implicit 
mappings as long as explicit mappings take precedence. ".

It says, that ANY explicit mapping MUST take precedence over ANY implicit 
mapping done within the container. (Whereas the preceding phrase in the spec is 
a little bit misleading because one might think that only explicit SUFFIX 
mappings take precedence. However the first statement is only meant as an 
example.

I must say, that the statement made in the spec is not all too clear and allows 
for different interpretations. One hint, that underscores my way of 
interpreting it is, that it would make sense do do it that way! Why should a an 
implicit jsp mapping made by a container precede settings made by a webapp. 
What for?! On the other hand, the example of the webdav servlet clearly shows 
that the opposite behaviour would be desirable.

Again, your answer was valuable to me, and it was correct to close this bug 
report because there is nothing wrong with the webdav servlet, but IF tomcat 
should REALLY behave as you have suggested, then another bug should be opened 
reporting on the wrong behaviour of tomcat concerning implicit mappings.

What's your opinion?

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