Note that including a resource by SSI is under the access control of
DeleGate (as origin or proxy server) common to the access control
against client users. That is, if a client user is forbidden to
access the included resource, it is also forbidden even via SSI-include.
Especially allowing including a resource out of the DeleGate server,
with URL like virtual=http://exserver/dir/fileX
can make a security hole made by a user as a SHTML writer.
In an origin server, relaying as a proxy must be forbidden by
RELAY=no, but it also forbids SSI-include to do
from other servers.
A simple workaround in version 9 is adding a limited RELAY as
RELAY="proxy:http:exserver:*" that only allows
relaying to exserver.
Another safer workaround is using MOUNT like
MOUNT="/ex/* http://exserver/dir/*" then write SSI-include like
But both of these allows client users to access to resources
other than the intended virtual URL in the exserver.
To cope with the above problem in version 10, RELAY=ssi is
introduced to be used together with RELAY=no. RELAY=ssi allows
SHTML writers to do include from other servers, leaving the permission
for client users unchanged (as RELAY=no).
In other words without RELAY=ssi, you (as the administrator of DeleGate)
can forbid SHTML writers to include from other servers.
Also you can restrict the includable target server (and protocols or clients)
by the generic notation of DeleGate as
Another (and maybe more important) extension in version 10 is relaying
request/response message header (as Cookie or User-Agent) back and forth
between client and server via SSI-include.
NOTE: Maybe it is impossible to forbid CGIs to access arbitrary servers
in a way independent of platforms and languages.
But at least we can forbid CGIs completely with