This commit fixes #2 (git.destrealm.org). See notes.
Chiefly, the primary mistake I made was in the capstanContext. More
specifically, it was in the capstanContext.WriteJSON() function which
was itself calling c.Write() rather than c.response.Write(). I believe
this was due to the changes made to wrap the response calls so we could
handle errors internally, allowing callers to return the context from
their controller methods rather than being forced to return an error.
I had a feeling this design would eventually bite me because it requires
a fairly substantial amount of caution in its design.
What eventually happened was that, for whatever reason, a race condition
would (sometimes) trigger if the remote endpoint killed the connection
at just the right time, allowing WriteJSON to set the value of lastError
to the current context because of its call into c.Write() rather than
c.response.Write(). This would cause a cascade of failures the moment
the goroutine stack overflowed bringing the whole application down. This
could have caused a denial-of-service attack by simply combining a) code
that called Context.Error() and b) found an endpoint that delivered a
large enough response that the connection could be torn down before the
server had a chance to finalize its response.
Fortunately, "a" is likely to be uncommon, because there isn't much
reason for clients to call Context.Error(). Since clients are encouraged
to return the context itself in the event of an error (this happens
transparently; some context functions returning errors actually return
an error wrapped by that same context), I don't believe there is
currently any code out there that would use this method directly.
To prevent this from happening again, I have taken the precaution of
implementing the following:
* ALL calls internal to the Context that set c.lastError now pass the
value through c.SetError().
* c.SetError() will now panic if it is passed a Context.