Jesse Szwedko

@trevrosen It looks like you opened #245 after this comment so I assume you realized this wouldn't help with #244, but let me know if you still think it would...

I agree that it is a little inconsistent, but I hesitate to modify this part of the API until a version `2` given the severity of the breaking change.

Hi @Vikash082, Unfortunately the `Recovery` middleware will not catch `panic`s occurring in a separate goroutine (see #190 for more information). I'm not super familiar with the context timeout pattern myself,...

Hi @Vikash082, I would move `next()` out rather than adding an additional `defer recovery`, but that is just my preference. The only advantage I see to that is to just...

Ah, yes, I see. After looking more closely at `net/http`, it looks like `r.WithContext` is meant to be used when _issuing HTTP requests_ rather than when responding to them. It...

Hi @baijum, While I agree with you that `false` makes a more sensible default for this, unfortunately this default has existed since the `Recovery` middleware was introduced in 6939988 so...

@pjebs can you clarify what you mean by > There is a subtle but crucial difference to adding code after `next(rw, r)` I'm not sure I see the difference.

It'd be nice if this didn't require buffering the output, but I see what you are going for. Because I feel like many users would not want to buffer the...

:+1: I'm cool with making it the default in `Classic()`

I'm seeing this as well, but strangely only in certain build environments (cannot reproduce locally, can reproduce in TravisCI -- same versions of phantomjs, ruby, etc.).