tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danno Ferrin" <DFER...@novell.com>
Subject Re: [PATCH]: state handling in JspReader
Date Tue, 14 Dec 1999 19:57:59 GMT
<off-topic>
On the subject of spec changes, is it me or has every request to 
fix table2-4 in the spec been ignored in every revision?
</off-topic>

I think that the real problem is that an arguement can be made for
both forms of include, wether treating it as a C #include <foo.h> or
a #include "foo.h" <sarcasm>(which everyone knows all the 
implications of since we all have the ISO C standard memorized, right?</sarcasm>

The behavior of <jsp:include ...> seems to be that of of relative to
the page owning the inlcude directive, althought the behavior of
<%@ include ...%> seems to me to favor relative to the requested page
and not the page owning the <%@include ...%>.  (2.7.6 Par. 1 and  2.5.2)
but the problem is then the two include mechanisms behave 
DIFFRENTLY when it comes to the treatment of nested includes.  I actually
favor changing or clarifying the spec with reguard to this so that the nested
include has the context of the page actually holding the include directive 
but also subject to the access limitations imposed on that page and all 
"parent" pages, there are some convoluted ISP examples I could 
counjure up involving security where you would want to inherit acces
restrictions.  Perhaps a vote to see what the jakarta projects interpretation of
the spec calls for in nested includes would be in order?

--Danno

>>> rubys@us.ibm.com 12/11/99 05:23PM >>>


Alex Cruikshank wrote:
>This should work, but JspReader only stores the base directory of the
>original file (the "master" variable), so when it tries to look up
>include3.jsp, it looks in /dir2/include3.jsp instead of
>/dir1/dir2/include3.jsp.  This is clearly incorrect behavior (how is
>include2.jsp supposed to know the base dir of the file that included it?).

Quite arguably undesirable, but incorrect?

I believe this was discussed previously on this mailing list (though I
can't seem to find the reference at the moment...)  The interpretation of
the spec at the time was that an include directive is supposed to behave
exactly as if the literal bytes in the referenced resource were substituted
in place of the directive.  If this is carried out literally, then the
current JspReader behavior is correct.

If this is to be changed, it must be done by first correcting the spec.



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



Mime
View raw message