tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Cruikshank <a...@epitonic.com>
Subject Re: [PATCH]: state handling in JspReader
Date Mon, 13 Dec 1999 19:32:26 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message