CGI Security Documentation

CGIWrap To-Do List

This page outlines some of the work that still needs to be done in CGIWrap, along with ideas for future improvements and possible feature directions. It serves as a lightweight roadmap, showing which parts of the software were seen as unfinished, which areas could be refined further, and which ideas might improve CGIWrap’s flexibility, usability, or security in later development.

A to-do page like this is useful because it reveals where the software’s author saw opportunities for improvement. Instead of only documenting what CGIWrap already does, it also captures the next layer of thinking around better debugging output, environment handling, user directory mapping, and stronger operational controls.

Current To-Do Items and Future Ideas

Here are some things that still need to be done and ideas for possible future work. While some of these are smaller cleanup items and others are broader feature ideas, together they help show where CGIWrap could be extended to become more polished and more flexible in real Unix CGI environments.

Fix PATH_TRANSLATED support

PATH_TRANSLATED handling has long been one of the recurring problem areas in CGI environments, so improving it would help make CGIWrap more reliable and more predictable for scripts that depend on translated path information.

Provide an HTML version of cgiwrapd output

An HTML-based version of cgiwrapd instead of text/plain could make debugging output easier to read and more structured for users who rely on browser-based troubleshooting.

Make user directory mapping more flexible

A more flexible approach to user directory mapping, including a rewrite file and mapping directory to user instead of user to directory, would make CGIWrap easier to adapt to less conventional hosting environments.

Limit script execution based on load average

Adding the ability to restrict execution based on system load could give administrators another way to protect server stability when CGI activity becomes too heavy.

Allow any environment variable to be set from CGIWrap

More flexible environment variable handling would make CGIWrap easier to integrate with a wider range of script requirements and hosting conventions.

Finish the request information section of error output

More complete request information in error output could make diagnostics clearer for both administrators and script authors who need more context when a script fails.

Use SERVER_ADMIN and other HTTP variables

Better use of available HTTP environment variables could improve local documentation references, error reporting, and context-sensitive information presented to users.

Clarify behavior when HTTPD user checking is disabled

If HTTPD user checking is disabled, you need to make sure the installation group is set to the group the server is running as and that permissions are restricted carefully. This note points to both a documentation need and an area where safer handling could be emphasized further.

Continue creating global context for storage of data

Continued work on global context handling suggests an interest in cleaner internal state management, which could help CGIWrap become easier to extend and maintain over time.

Taken together, these items show that the future direction of CGIWrap was not centered on changing its core purpose, but on improving surrounding details: clearer diagnostics, stronger flexibility, better integration with real-world hosting setups, and tighter operational controls. That makes this page a useful complement to the change log because it captures not what was finished, but what still seemed worth doing.