Jeremy Evans

@tenderlove I've rebased this against current master. Can you approve (or request changes)? This is the last blocker for Rack 3, AFAIK.

> I personally like this kind of interface, but I'm not sure if this fixes the existing semantic issues with `get/set_header`. It doesn't attempt to fix the semantic issues. We...

> How do we deprecate the existing methods without introducing the same backwards incompatible change? Basically this doesn't seem to solve the original problem. As I've stated, I don't think...

> I'm fine punting both PRs for later in the Rack 3.x release cycle, but I'd like to hear input from others before making a final decision. I think introducing...

> `Rack::Lint` seems to validate that middleware implements the spec correctly but `rack.response_finished` is completely dependent on the server implementation. Is there a standard way to validate that a server...

> Is `rack.after_reply` compatible with the proposed spec? Other than the key, it seems to be compatible: * Unicorn: `env["rack.after_reply"].each(&:call)` * Puma: `after_reply.each { |o| o.call }` There is no...

Unless we can identify significant problems, I believe we should adopt existing de facto standards as already implemented. @tenderlove agrees (https://github.com/rack/rack/pull/1701#issuecomment-666525691): > If popular web servers all do it, then...

> @jeremyevans that's not what @tenderlove said: [#1777 (comment)](https://github.com/rack/rack/issues/1777#issuecomment-1023768075) What I quoted is what @tenderlove said in issue #1701. It is a general statement about how we should treat a...

@tenderlove I think your guidance is needed here to decide whether we should officially bless the de facto standard `rack.after_reply` (implemented by Puma and Unicorn), or standardize a different (perhaps...

> I doubt there's much to be done with the return value, but passing `env` might allow some users to avoid needing a per-request allocation, instead of having to rely...