Closed streams should probably result in errors, not recovered panics.

[scottmmjackson]

Proof of Concept here: https://gist.github.com/scottmmjackson/c35f4609750d9c6907a464780e55097a

Adding r.Use(gin.Recovery() does not change the outcomes below.

Do a curl https://localhost:8080 -k (especially with nghttp2 support built in) and CTRL+C (or TERM, or KILL) before the server has a chance to read a response. The result should be something like:

http2: panic serving [::1]:54808: http2: stream closed
// stacktrace here

Similarly a curl http://localhost:8181 that's terminated too early:

http: panic serving [::1]:54806: write tcp [::1]:8181->[::1]:54806: write: broken pipe
// stacktrace

That Context.JSON panics when the stream is closed too early means that in larger apps it's much more difficult for the app to gracefully degrade. The recovery handler is thus handling app-created panics (e.g.: the dev messed up) as well as panics that will necessarily occur in real-world use cases (e.g.: the user stopped loading the request, or a proxy reset the connection early).

It also pollutes stderr with stack traces that show that, yes, in fact, a user closed the socket before we could write the response.

[easonlin404]

@scottmmjackson Could you help to replace gopkg.in/gin-gonic with github.com/gin-gonic?
I tested and had no problem with github.com/gin-gonic.

[aronatkins]

This appears to have been resolved by #2150, as the render helpers no longer panic.