I have implemented CGI supported and commited to cvs. First what it
does (or should do, at least):
If you are requesting a file ending in `.cgi' or `.CGI', Yaws will
(try to) execute it as a CGI program. If you are requesting a `.php',
Yaws will execute php and pass the location of the script in an
environment variable. If you do not want to have the scripts among
your ordinary files, you can also write a `.yaws'-wrapper using
A request to
will result in calling /a/b/c.cgi, if it is a plain file, passing
`/d/e' as PATH_INFO.
This also works for `.yaws'. A request for
will actually call /a/b/c.yaws with Arg#arg.pathinfo set to "/d/e".
This can be used as an appmod replacement. It can be more convenient,
because after changing you do not have to recompile an reload by hand
(look at `yaws -load module', btw). It is user visible however, while
appmods are completely invisble.
Not all CGI variables are set to the correct values. Help is welcome!
It should be possible to turn this feature of. I am thinking of
something like a configuration variable `allowed_scripts' with a
default value of "yaws" which could be set to "yaws cgi" or "php" etc.
At the moment `php' is look for in the path, a full path should be
configurable. BTW, is it possible to call open_port not to use the
shell when spawning a process, but to call the program directly?
All scripts are running as the same user as Yaws. This is not more
dangerous then allowing `.yaws' files, but solutions should be
considered anyway. This may indeed be useful, if you are having
virtual servers for which you disable `.yaws'. Also standard CGIs you
are using might have security problems.
Comments and testing are welcome.
Carsten Schultz (2:40, 33:47), FB Mathematik, FU Berlin
PGP/GPG key on the pgp.net key servers,=20
fingerprint on my home page.