Matthew Holt 2a46f2a14e Revert recent Content-Length-related changes and fix fastcgi return ...

fastcgi's ServeHTTP method originally returned the correct value (0) in
b51e8bc191da8c84999797caeb0c998d4305d088. Later, I mistakenly suggested
we change that to return the status code because I forgot that status
codes aren't logged by the return value. So fastcgi broke due in
3966936bd6f01462fb8b41198bf36a83e17ad6e7 due to my error.

We later had to try to make up for this with ugly Content-Length checks
like in c37ad7f677b9122544ab2d2384ef8ef2b76bd970. Turns out that all we
had to do was fix the returned status here back to 0. The proxy
middleware behaves the same way, and returning 0 is correct. We should
only return a status code if the response has not been written, but with
upstream servers, we do write a response; they do not know about our
error handler.

Also clarifed this in the middleware.Handler documentation.

2016-03-02 11:33:40 -07:00

..

errors_test.go

Revert recent Content-Length-related changes and fix fastcgi return

2016-03-02 11:33:40 -07:00

errors.go

Revert recent Content-Length-related changes and fix fastcgi return

2016-03-02 11:33:40 -07:00