We might end up calling client_close() from start_reply(), but that will free the fcgi/proxy bufferevent while they're still used on the stack. Instead, start_reply() only sets REQUEST_DONE and exits, returning the error eventually, so callers know when to stop.

The idea is to require SCRIPT_NAME to be defined and strip it from the beginning of the path to get PATH_INFO. Soon(tm) a `fastcgi request strip' option will be added too. Maybe even `fastcgi script name "path"` that sets SCRIPT_NAME automatically.

this revamps the syntax in the configuration to better match httpd(8) (and in general be less weird) and to allow per-location fastcgi configurations. the bare `param' is now deprecated, but for compatibility it acts like `fastcgi param' would do now. Same story for `fastcgi <pathÂ>'.

Listening by default on all the addresses is so bad I don't know why I haven't changed this before. Anyway. Add a `listen on $hostname port $port' syntax to the config file and deprecate the old "port" and "ipv6" global setting. Still try to honour them when no "listen on" directive is used for backward compatibily, but this will go away in the next next version hopefully. At the moment the `listen on' in server context don't filter the host, i.e. one can still reach a host from a address not specified in the corresponding `liste on', this will be added later.