On Tue, 3 Apr 2001, Amy Roh wrote:
> (1) According to NCSA "virtual gives a virtual path to a document on the
> server." So no matter which context you're in, <!--#include
> virtual="/test.txt" --> should try to access "test.txt" on your server's
> root, right? Does virtual have to start with "/" always? I would think
> so. If not, what should be the behavior if it doesn't start with "/",
> context based?
If I remember this - "context based" is something specific to servlets
( 2.2 and after ), the /paths are allways relative to the server ( or
vhost ) root URI.
One tricky part is that /foo/bar.txt may not refer to the file
ROOT/foo/bar.txt - it may be mapped by the server to a different location
( Location is similar with a servlet context - so it may be in context
foo, with a different docbase ).
Apache is doing a re-mapping ( run_subreq ) to get to the right file ( the
relevant file is httpd-2.0/modules/filters/mod_include.c ).
That mean you need to do use a request dispatcher or something equivalent
to make sure the path is mapped ( and of course to play some games with
the URIs to match the servlet and http server semantics ).
I think the security rules are also applied during include - but you
should test that.
> (2) Also, NCSA states "file gives a pathname relative to the current
> directory." So obviously <!--#include file="test.txt" --> should try to
> access "test.txt" in your current directory. What about "<!--#include
> file="/test.txt" -->"? Should that look for "test.txt" on your server
> root or on webapp?
Again, distant memories - but include file was supposed to be the
"fast" version that doesn't do mapping/auth/etc - so it is limited to the
local directory ( and I think it didn't do security checks either ).
Sorry, I used SSI long ago ( I think it was a Cern server ), but I
still remember some pain :-)
Costin
