Did you view source the page? Is the comment there? If you're not getting any error message with the "AddHandler/AddType" Directives and "Options Includes" is set in the area of the site you're accessing, SSI is probably working, however SSI syntax is _SUPER_ anal, I've ripped my hair out many a time because I left a space where i shouldn't or put the "#" symbol in the wrong place.
On Sunday, February 3, 2002, at 11:22 AM, ME wrote: > On Sun, 3 Feb 2002, Peter Jay Salzman wrote: >> for some reason, SSI isn't working and i have no idea why. the page >> that i'm trying to make work is: >> >> http://www.dirac.org/pcgm/bulletinboard.shtml >> >> in /etc/apapche/srm.conf, i have the lines: >> >> AddType text/html .shtml >> AddHandler server-parsed .shtml >> >> i didn't put this in the file myself -- the config file came from >> debian >> with these lines commented out, and i uncommented them. >> >> of course i restarted apache, many times. i even ran strace to make >> sure it was reading this file (overkill, but i'm at a total loss here). >> >> the server just seems to be totally ignoring the SSI stuff, and i'm not >> seeing anything in the apache logs that's helpful. >> >> anyone have suggestions on why SSI may not be working? > > You prob need to modify the <directory> </directory> section for the > relative location used in the server to add an OPTIONS entry to allow > SSI > to take place. > > If you choose not to do this, you can take the less secure route, and > not > modify the Options entry but instead add "AllowOverride All" and then > create .htaccess files in directories that specify what options to have. > > In particular, you prob want ( > IncludesNoExec > or > Includes > > added to your options entry > (example:) > Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec > > These you will want to avoid if others may write data to the directory > (security reasons): > ExecCGI : Allows user to create programs (cgi) that run on the server > with perhaps their UID, the default apache uid, or nobody. When the > users are not permitted shell access, this effectively may allow them > to > have *some* shell access - though a bit clunky. > FollowSymLinks : If they can manage creation of a symlink to /etc/passwd > (they being ?) then your /etc/passwd file may be web page publishable > Includes : this allows for the #exec in arbitrary execution of commands > on > the server which can also be a clunky shell. > > > When you look to add these, make sure to add them where your <directory> > references the actual directory you are coding. If there is only one > <directory> entry, then that would be the place to do it. > > The apachedocs manual explains the options and directory system quite > well. > > For example, in the FAQ that ships with apache there is a section on > SSI: > > "F. Dynamic Content (CGI and SSI)" > > "1. How do I enable CGI execution in directories other than the > ScriptAlias?" > > "7. How do I enable SSI (parsed HTML)? " > > -ME > > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) > P+$>+++ > L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP > t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z? > ------END GEEK CODE BLOCK------ > decode: http://www.ebb.org/ungeek/ about: > http://www.geekcode.com/geek.html > Systems Department Operating Systems Analyst for the SSU Library > > _______________________________________________ > vox-tech mailing list > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech > > --- Sam Peterson Hart Interdisciplinary Programs 2201 Hart Hall University of California, Davis One Shields Avenue Davis, California 95616 (530) 752-9332 _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
