This is a common enough question that it's worth calling out explicitly.

It turns out WriterProxy is pretty generally useful, especially when
defining custom http loggers. Expose it in a util package so that other
packages can use it.

Many common panic values, e.g. nil pointer dereferences, don't print
very well under "%#v", emitting something like
"runtime.errorCString{cstr:0x54b2a4}" or similar.

If WriteHeader is called multiple times on a http.ResponseWriter, the
first status is the one that is used, not the last. Fix the wrapped
writer to reflect this fact.

Change the per-process nonce part of the request ID from 8 characters to
10, and wrap the entire thing in a retry loop so you can never get an
"unlucky" panic. I know this will "never" happen in practice, but it
doesn't hurt to make sure we never, ever have any collisions, and never,
ever have any runtime panics.

It's also worth documenting the math ("math") I used to calculate the
numbers here.

This middleware allows you to override a http.Request's RemoteAddr with
a value derived from either the X-Forwarded-For or X-Real-IP headers.

Fixes #12.

Provide a standard middleware to set c.Env. Don't include it in the
default stack, however, since the RequestID middleware will end up
allocating Env anyways.

Fixes #11

They're really verbose. I should probably DRY them up later.

httptest was adding an extra flag, which was sort of ugly. Instead,
reimplement the parts of its functionality we were using. Bonus: due to
specialization, it's now a bit more efficient as well!

Who knew! (RFC 2616, 5.1.1)

For sendfile(2) support. I should really DRY up the implementations here...

In order to avoid a dependency on the go.crypto terminal package, let's try to
do our own TTY sniffing. I think in practice this will work surprisingly well,
even if it feels incredibly sketchy.

I've currently written three:
- Request ID generation
- Request logging, with color (!)
- Recovery from panics