relative directories and nested includes

[ru...@us.ibm.com]

This is a discussion that took place on the tomcat-dev mailing list, but
never came to a conclusion.  I'm hoping that bringing it up here will.  The
question is whether a nested include is to be interpreted relative to the
immediately including scope or relative to the original page.

My input is:

1) while it has been suggested on the tomcat-dev mailing list that this be
resolved via a vote, I strongly feel this is not an area best left to
individual implementor's interpretation.  In fact, the problem came up when
Alex attempted to move a large site from GNUJSP to Tomcat/Jasper.  Clearly,
any perceived ambiguities in this area will seriously detract from the
portability aspects which are so important to JSPs.

2) while I do not feel as strongly about how this issue is resolved, I do
feel that treating nested includes as relative to the immediate page from
which they are included (as Alex suggests), is more intuitive and useful.

3) the amount of code in question is not large.  In fact, the only changes
required to Jasper are in a single method in JspReader.  Alex has already
submitted a patch, and I am prepared to commit it once I am convinced that
it would be appropriate to do so.

In the absense of guidance to the contrary, I'm inclined to make this
change.

- Sam Ruby

---------------------- Forwarded by Sam Ruby/Raleigh/IBM on 12/21/99 08:31
AM ---------------------------

Alex Cruikshank <al...@epitonic.com> on 12/13/99 02:32:26 PM

Please respond to tomcat-dev@jakarta.apache.org

To:   tomcat-dev@jakarta.apache.org
cc:
Subject:  Re: [PATCH]: state handling in JspReader



comments below.

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

Also unintuitive, but I would argue still 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.


We can keep this literal interpretation without causing the undesirable
behavior.  It just depends on the ordering of the include operations.  If
you consider the resource being included in include1.jsp to be include2.jsp
with all of its included files already included (which, I think, is
logical), then there is no problem.  It's a matter of:

( page1.jsp include ( page2.jsp include page3.jsp ) )

instead of

( ( page1.jsp include page2.jsp ) include page3.jsp )

In the first case, (which is, incidentally, the way the file is actually
parsed) it seems obvious that page3.jsp should be found relative to page2
rather than page1.jsp.


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

I can't find anything in the 1.1 spec that suggests that included files
should be included first, then have their includes processed.  Indeed,
doing so would suggest using a multi-pass parsing algorithm.  The only
thing that seems relevant in the spec is section 2.5.2 on relative paths:

...
When such a path does not start with a "/", it is to be interpreted
relative to the current JSP page: the current page is denoted by some path
starting with "/" which is then modified by
the new specification to produce a new path that starts with "/"; this
final path is the one interpreted through the ServletContext object. We
call these paths "page-relative
paths".

JSP uniformly interprets all these paths in the context of the Web server
where the JSP is deployed; i.e. the specification goes through a map
translation. The semantics applies to translation-time phase (i.e. include
directives, Section 2.7.6), and to request-time phase (i.e. to include,
Section 2.13.4, and forward, Section 2.13.5,actions). If a specific tool
can ascertain by some mechanism the status of the URL to resource maps at
deployment time, the tool can take advantage of this information.  With the
appropriate assertions, the translation phase might be performed before
deploying the JSP page into the JSP container.

It would seem to me that the "current JSP page" would be page2.jsp, not
page1.jsp.  If this is the case, page3.jsp should be found relative to
page2.jsp.  Is this not the case?

Alex Cruikshank
Software Engineer
Epitonic.com
alex@epitonic.com

Re: relative directories and nested includes

[Hans Bergsten <ha...@gefionsoftware.com>]

rubys@us.ibm.com wrote:
> 
> This is a discussion that took place on the tomcat-dev mailing list, but
> never came to a conclusion.  I'm hoping that bringing it up here will.  The
> question is whether a nested include is to be interpreted relative to the
> immediately including scope or relative to the original page.
> 
> My input is:
> 
> 1) while it has been suggested on the tomcat-dev mailing list that this be
> resolved via a vote, I strongly feel this is not an area best left to
> individual implementor's interpretation.  In fact, the problem came up when
> Alex attempted to move a large site from GNUJSP to Tomcat/Jasper.  Clearly,
> any perceived ambiguities in this area will seriously detract from the
> portability aspects which are so important to JSPs.

I agree; it needs to be clarified in the spec.

> 2) while I do not feel as strongly about how this issue is resolved, I do
> feel that treating nested includes as relative to the immediate page from
> which they are included (as Alex suggests), is more intuitive and useful.

I agree.

> 3) the amount of code in question is not large.  In fact, the only changes
> required to Jasper are in a single method in JspReader.  Alex has already
> submitted a patch, and I am prepared to commit it once I am convinced that
> it would be appropriate to do so.
> 
> In the absense of guidance to the contrary, I'm inclined to make this
> change.

It would be great if we can get some guidance from Eduardo on this before
any changes are done in Tomcat.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com