On Fri, 5 Nov 1999, Blue Boar wrote: > The format of the command is part of the problem, and why I'm thinking > there may be some sloppiness in Apache. It appears that there is an > assumption that SSI commands tend to be on lines by themselves, and are of > the format: > > <!--# (SSI command) --> Maybe there is an assumption by some people that SSIs be on a line by themselves, but that is not Apache's fault and I do not think it is reasonable to suggest that Apache should reject SSIs that do not conform to that particular misconception. Note that the following is a valid SSI: <!--#include file="/foo1" file="/foo2" file="/foo3" --> Apache does "reject" invalid SSIs, but does not validate that a SSI is valid before it begins processing it so the rejection only happens after it has been partially processed. One reason for this is that a SSI directive can be of an unbounded length as demonstrated by the example above. It may be a reasonable tradeoff to limit this (since it has little practical use) in exchange for ensuring that a SSI is well formed before starting to process it, and expressly documenting what that form is. There are, however, reasons why it behaves in the manner that it currently behaves in. As always, don't enable SSIs unless you need them. If you do need them, use IncludesNOEXEC (which does not allow random files to be executed, but does allow CGIs in ScriptAliased directories to be executed) unless you really need to allow exection of other things. If you really do need to allow execution of other things, don't do it globally, but only where it is absolutely necessary. Unfortunately, the issue isn't as simple as just Apache. Apache is but one of dozens or hundreds of servers that support what they call SSIs. However, these SSIs are not the same thing across all servers; they can very in very obvious ways, or there can just be less obvious syntactical differences.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:09:52 PDT