| 1 | www-cgi/: Allow customization of the environment filters. |
| 2 | |
| 3 | Sites can now configure `ucgi's environment filters, and end users can |
| 4 | configure `ucgitarget's filters. |
| 5 | |
| 6 | By default, `ucgi' will look in `/etc/userv/ucgi.env-filter', but if |
| 7 | `UCGI_ENV_FILTER' is set in its environment, it will look there |
| 8 | instead. The filter may contain wildcards and so on. |
| 9 | |
| 10 | By default, `ucgitarget' looks in `.userv/ucgitarget.env-filter', or |
| 11 | `/etc/userv/ucgitarget.env-filter', if the former doesn't exist; but if |
| 12 | passed a `-e FILTER' option on its command line, it will look in the |
| 13 | file FILTER instead. This filter may /not/ contain wildcards. |
| 14 | |
| 15 | In both cases, if an explicitly named filter file can't be found then |
| 16 | the program fails; if the default filter files can't be found then they |
| 17 | fall back to built-in lists. |
| 18 | |
| 19 | The reason for the asymmetry in interfaces is: it's hard to pass |
| 20 | command-line options to CGI scripts from webservers, but pretty easy to |
| 21 | set environment variables; whereas it's hard to pass environment |
| 22 | variables to a service program in a Userv configuration file, but easy |
| 23 | to pass command-line arguments. |
| 24 | |
| 25 | |
| 26 | www-cgi: Introduce `?DEFAULTS' pattern to match the default set. |