Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <4.2.0.58.19991214145329.00b57220@pop.epitonic.com>
Date: Tue, 14 Dec 1999 15:32:36 -0800
To: tomcat-dev@jakarta.apache.org
From: Alex Cruikshank <alex@epitonic.com>
Subject: Re: [PATCH]: state handling in JspReader
In-Reply-To: <s8563f47.036@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_512400212==_.ALT"

--=====================_512400212==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


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

Re-reading these paragraphs for the sixth time, I still don't see anything 
that suggests include directives should be processed relative to the 
requesting page (unless, somehow, "current page" refers to the requested 
page instead of the page currently being parsed), so I agree that this 
issue needs to be clarified in the spec.

The "relative to the requested page" interpretation will adversely affect 
the utility of both the <jsp:include> and <@ include> commands, because 
pages with relative includes (of either type) cannot be included from pages 
outside the directory they belong to.  This seems a needless restriction 
(so long as the pages do inherit the security restrictions of the requested 
page), especially since the only thing it seems to add is confusion for 
application programmers.  Is there something I'm missing?

>restrictions.  Perhaps a vote to see what the jakarta projects 
>interpretation of
>the spec calls for in nested includes would be in order?

I'm whole-heartedly in favor of a vote.

- Alex

PS. Regardless of the interpretation of nested includes, an include 
directive at the end of a JSP page (with no trailing spaces) still causes 
the Jsp compiler to throw an ArrayIndexOutOfBounds exception.  A problem 
that, IMHO, should at least be acknowledged as a known bug before the 
release. Thanks.

>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
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

--=====================_512400212==_.ALT--