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=4326>. 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=4326 SSI servlet isVirtualWebappRelative parameter does not work Summary: SSI servlet isVirtualWebappRelative parameter does not work Product: Tomcat 4 Version: 4.0 Final Platform: Sun OS/Version: Linux Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Server side include servlet accepts an isVirtualWebappRelative parameter, defined in tomcat4/conf/web.xml. The parameter value '0' (false, the default!) should make server side virtual paths relative to server root. This does not however seem work :-/ In particular, if in server.xml we first define two contexts: <Context path="/archive" docBase="/home/ibs/archive"/> <Context path="/tk" docBase="/home/ibs/tk"/> where the files in the /archive context contain SSI references: <!--#include virtual="/tk/tyyli_yleinen_ibs.ssi" --> and the files in /tk context contain the corresponding SSI files: /home/ibs/tk/tyyli_yleinen_ibs.ssi In web.xml, we then (try to) make virtual references relative to root: <init-param> <param-name>isVirtualWebappRelative</param-name> <param-value>0</param-value> </init-param> If we now try to access files that contain SSI directives: http://localhost/archive/testfile.shtml The result is a SSI error [an error occurred while processing this directive], even if: http://localhost/tk/tyyli_yleinen_ibs.ssi is available and works fine. If we then ignore the /tk context, set 'isVirtualWebappRelative=1' and rename the /home/ibs/tk directory as /home/ibs/archive/tk, and therefore make the SSI files to appear as: http://localhost/archive/tk/tyyli_yleinen_ibs.ssi the SSI include mechanism produces the expected result. It would therefore seem that the 'isVirtualWebappRelative=0' fails to resolve virtual paths, or download file content. If it is the downloading that fails, one possible reason for this could be that loading files from some other context is not permitted for some reason. Without any error messages anywhere, it is however hard to tell. It is a very typical scenario that SSI virtual paths should be interpreted relative to server root (that's why it is (or should be) the default behaviour, too). Such files should also to be able to reside in different contexts.
