
- NPH support optional bzw. irgendwie
  erkennen!

- linux probleme. 
- tests unter anderen OS
- test suite

- debug mode -x realsieren mit buffer vorher, 
  nach convertierung und nachher

- security problems sperl taint?

- security: !!! Als Filter darf natuerlich nicht
  auf den User geswitcht werden und es sollte
  das u+x durch ein seteuid(getuid) und seegid(getgid)
  eliminiert werden.

- Eventuell als Option beim Compilieren oder unter Runtime:
  Entweder seuid und taint mode _ODER_ nonuid und kein taint mode

- bei shebang sollten parameter erlaubt sein,
  um z.B. delimiter umzusetzen oder eben auch, um
  den taint-mode (siehe oben) umzustellen, etc.

- neben Apache Anleitung zur Nutzung auch
  NCSA und NSAPI Zeugs und auch CERN

- dumps core for "dumps" file

- bei CGI delimniters anders setzen als bei Standalone

- ausgabe cachen wenn HTTP_PRAGMA=no-cache nicht gesetzt ist.

- eventuell page output cachen 

- eventuell page output mit last-modified verzieren.
  vielleicht nur, wenn gar keine ePerl direktiven drin sind.
  Besser ist wohl: Output erzeugen, md5 sum erzeugen davon
  dann vergleichen mit gespeicherter md5sum und wenn
  gleich, last-modified von damals ausgeben.

- HEAD requests verstehen!

- bei nur shebang als file.cgi darf kein NPH Zeugs ausgegeben werden
  also auch kein HTTP/1.1 header.
  StripHTTPHeaders noch erstellen!!!!!!!

- logfile nutzen!!

- age nutzen!!

-------

- typedef bool char fuer Linux mit GNU autoconf testen

- Security:
  ptht is more secure than allowing users access to cgi-bin. In the Safe
  module where the web-code is executed, admins can restrict access to
  sensitive commands like chown and system.

  Am besten waere: ePerl ist setuid root und switcht selber auf
  die UID des File-Owners!

- bei aufruf von Kommandozeile, sollte ePerl vielleicht (optional)
  ein CGI env emulieren fuer debugging

> One more question: Have you given any thought to some of the neat
> things PHP does when it's an Apache module like complete control over
> the headers that go out and the ability to do authentication according
> to any scheme you dream up by giving your HTML File/Program/Script
> (whatever you call these have static have dynamic things we create)
> direct access to the authentication messages to and from the client?
> This would be a very useful component since it would allow me to
> authenticate web page access using a radius client module, etc.

- best: eperl  -- standalone CGI script
        eperld -- standalone runnign eperl server
		mod_eperl.c -- Apache module to interface with eperld

- perhaphs the servers DocumentRoot should be used?

- SSI Variables should be set (LAST_MODIFIED, USER, etc.)

- Version Splicer should be uses internally: 
  - version.control file 
     default    2
	 3          2
	 3N         3N
	 3NJ        3
	 Mozilla/2  3N
	 Mozilla/3  3NJ
  - this sets the $HV (html version) variable
  - use 
    <!--#eperl code='if $HV eq '3N' {' --> 
    <!--#eperl code='} else {' -->
    <!--#eperl code='}' -->
    or
    <!--#eperl if="$HV eq '3N'" --> 
    <!--#eperl else -->
    <!--#eperl fi -->

The CGI version of PHP/FI does not read any .htaccess files which may be
present in a directory. This means that if
you have files that are protected using the standard .htaccess server-based
access control feature, people could
potentially circumvent this security by loading the page through PHP/FI. Note
that this is not an issue for the Apache
module version of PHP/FI.

There are a couple of different solutions to this problem. The easiest is
probably to use the PATTERN_RESTRICT
feature found in php.h. This lets you define an extension (or a pattern of
extensions) which are allowed to be parsed by
PHP/FI. If a file does not have this extension and someone tries to load it
with PHP/FI, an access denied message will
appear.

Another solution is to use the PHP/FI access control mechanism to mimic the
access control setup you have in your
.htaccess file. Keeping this information in two places can be tedious though,
and the two systems don't share all of the
same features.

The problem can also be solved using file permissions. PHP/FI can be set up to
run setuid as any user you wish. Then
files that are to be read by PHP/FI can be given appropriate permissions and
files not to be read by PHP/FI should be
owned by another user id and have their permissions changed accordingly.
