Remove all non-standard handlers.

[ioquatix]

Thin seems like an interesting server, but if you look at the issue tracker, it has not been maintained for many years. The recent changes to the thin handler have caused issues (#1583).

I don't think we should be maintaining handlers for servers in rack. They should provide their own adapters. If the maintainer of thin is not wiling to do this, should we be on the hook for trying to maintain it within rack? Including version checks?

Here is what I think I'd willing to do.

1/ I want to remove the thin handler.

2/ I want to move that code to the thin repository.

3/ I want a new release of thin with this code.

@macournoyer what do you think? What should we do?

[jeremyevans]

I think in 2.3 we should deprecate handlers that require libraries not shipped with Ruby, and then remove such handlers in 3.0. The handlers that only use libraries that ship with Ruby (webrick and cgi) we can keep and fully test.

[ioquatix]

This was also the advice of @tenderlove, so I'm happy to agree with that.

[macournoyer]

I think it make sense to remove the Thin handler from Rack. I agree handlers should be in the servers. I'd be happy to move the code to Thin and make a release.

[ioquatix]

Should we move these handlers into separate repos, e.g. rack-fcgi or rack-handler-fcgi?

[jeremyevans]

I don't think there is need to do that. We may want to reach out to the gem authors of the handlers and ask them to include the rack handler in their library if they want to support it. If not, users that want to continue using the handlers can copy the old version and maintain their own gem.

[ioquatix]

While I can accept that position, I also wonder if anyone will bother to maintain rack-handler-fcgi or if we will be fracturing the users of such an interface. That being said, I don't think it matters a huge amount to me personally.

[ioquatix]

I'm going to put this under the umbrella of #1593

[ioquatix]

I'm working on this now. I don't think there will be a 2.3 release of rack.