? on SSI virtual file
(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? (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? Amy
Re: ? on SSI virtual file
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? snip virtual gives a virtual path to a document on the server. You must access a normal file this way, you cannot access a CGI script in this fashion. You can, however, access another parsed document. /snip I would say that !--#include virtual="/test.txt" -- tries to access test.txt in the server's root. However if you read the rfc on virtual paths you can also use ., .., dir instead of starting with a / so then the following examples would/should work: !--#include file="file.txt" -- Which is a file in the current directory. !--#include file="./file.txt" -- Which is a file in the current directory. !--#include file="dir/file.txt" -- Which is a file in the "dir" directory _above_ the current directory. !--#include file="/file.txt" -- Which is a file on the servers root. !--#include file="../file.txt" -- Which is a file in the dir _below_ the current directory. (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? snip file gives a pathname relative to the current directory. ../ cannot be used in this pathname, nor can absolute paths be used. As above, you can send other parsed documents, but you cannot send CGI scripts. /snip As i enterpret this you can _only_ access a file using the file command in the following ways: !--#include file="file.txt" -- Which is a file in the current directory. !--#include file="dir/file.txt" -- Which is a file in the "dir" directory _above_ the current directory. !--#include file="/file.txt" -- Would fail. !--#include file="../file.txt" -- Would fail. And this is how it should be implemented right now. ..bip
Re: ? on SSI virtual file
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
