don't call client_close() from fcgi/proxy bev handlers 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.

move strip_path to utils.c

actually use the specified log style

add `fastcgi off' to forceful skip fastcgi for a route

revamp fastcgi configuration: make it per-location 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Â>'.

rename do_accept() -> server_accept()

change log_request to take the code and meta unpacked don't know what i was smoking when I wrote log_request() like that...

change on fatalx -> log_warnx we already check the validity of the format string, but still avoid a gratious fatal() at runtime.

rename fmt_sbuf -> fmtbuf; make the buffer explicit

avoid needless strlen()

simplify request handling get rid of check_path(), it's overly complicated. Instead, inline open_file() in client_read() and rework open_dir() to just use openat() instead of the complicate dance it was doing. Simplify open_dir() too in the process: if the directory entry for the index is not a regular file, pretend it doesn't exist.

use a function-local buffer for the canonical redirect

use snprintf() instead of chain of strlcpy/cat

call getnameinfo() only once per request

avoid gratious strlen; evbuffer_readln returns the length