webrick dependency necessary?

[Earlopain]

This repo was extracted from rack for v3, which previously didn't explicitly depend on webrick.

Webrick was dropped as a bundled gem from ruby 3 and the default web server for Rails is puma.

The other supported servers aren't depended upon and it would be nice if webrick is the same when I'm not actually using it.

[bombino]

This is now made worse by the fact that Webrick has a CVE filed against it: https://nvd.nist.gov/vuln/detail/CVE-2024-47220

[LarryEkohe]

Indeed! Let's see if we can see some changes soon as a fix seems to be ready and one of the maintainers has been tagged here: ruby/webrick#145 (comment)

[tisba]

With webrick as a direct dependency, it is kind of a nice out of the box experience currently: You only need to install rackup and you are ready to go. Directly running rackup with no arguments won't work anymore, if you forget to install webrick too. Not sure if I like that from an DX standpoint 🤔

In case webrick gets removed as a dependency, the webrick handler (Rackup::Handler::WEBrick) should probably be moved to the webrick gem.

[wlipa]

It's a little bit bothersome since Webrick is now marked explicitly as insecure for production use. If the out of the box for rackup experience is very important, perhaps the gem could be split into rackup and rackup_core (which would not depend on webrick). Then Rails could depend on rackup_core so that not all Rails apps have to pull in webrick.

ruby/webrick@d91c985

[ioquatix]

IMHO, rackup can be an optional dependency. Maybe rails should not depend on rackup but instead add it to the application gemfile which can then remove it if unused.

rackup is designed to get people started with minimal effort, but it's a poor substitute for actual server controls/configurations. That's something we could try to improve but it's tangential to the main use case as of today.

I would be okay with removing webrick as a dependency but in that case, rackup will be quite useless by default. IMHO, that goes against the principle of getting people started as easily as possible. But I also understand that it's pulling in dependencies that may not be useful.

If we did decide to remove webrick we should make sure we have clear documentation about how to use it, e.g.

gem "rackup"
gem "webrick" # or "falcon" or "puma" or "pitchfork" etc

I'd be okay with this if someone wants to work on a PR, but I'd also like to hear feedback from @jeremyevans.

[dentarg]

Removing the dependency on webrick here would make this message (https://github.com/sinatra/sinatra/blob/ef00c6a0db0ef31143e529e7e6edddf2d5c99653/lib/sinatra/base.rb#L1607) that Sinatra (in some situations) prints out a bit weird, I guess it could be patched to give even more instructions. When I added Rack 3 support to Sinatra I chose to not add rackup as dependency, as it would also bring webrick, which felt a bit weird for a framework to do.

I think it should be suggested to the Rails project to make changes on this matter.

[jeremyevans]

I recommend we drop the webrick dependency from rackup, so libraries that depend on rackup do not pull in webrick. I also recommend that libraries not depend on rackup. rackup as an executable made sense when webrick shipped with Ruby, so there was always a fallback. But that hasn't been true since Ruby 3.0.

I think frameworks/applications should just focus on providing config.ru files, so that users can use the webserver program of their choice directly (e.g. puma, unicorn, falcon). Maybe we could add a webrick program to webrick, so that webrick is more like other ruby webservers? However, it may be better not to, as I don't think we should do anything to encourage additional usage of webrick.

[ioquatix]

I am okay with that direction, so I'll cut a PR.