Feature: Standardize an API for Rack Handler to distinguish between user specified and default options

[schneems]

Context

For rack servers that have tiers of configuration they need ways to accurately determine what values came from where. Puma has: cli args, a ruby based config file, env var support, and default values. There is an explicit and consistent order to how these configuration operations are applied when running with the puma command, but when running via rack handler like rails server it's unclear if a port came from rails defaults or from rails server --port 3001.

If a user has a port(1234) in their puma.rb and we also get passed a :Port from the rack handler, we needed a way to know if it was user supplied or a default from upstream. We solved this specific problem already, but we didn't ever encode the behavior in the spec so other servers either have to magically discover this API or deal with worse integration (and other frameworks like Hanami) might not even know about this interface and get a worse integration.

Proposal

I propose we standardize some interface, either accepting the current Puma/Rails solution (which seems to have worked well and hasn't needed much work), or a new solution that meets the same needs and would allow for backwards compatability so frameworks like Rails can "dual boot" our old ad-hoc solution and a new "spec compliant" solution at the same time.

History

Here's the commit where I added that behavior puma/puma@85dfe8e as a part of PR puma/puma#1234 and on the Rails side rails/rails#28137.

Current code lives at: https://github.com/puma/puma/blob/38ded9c1e8e82a130a86e1135eb07aa76b58d8fb/lib/rack/handler/puma.rb#L22-L26

[jeremyevans]

We moved this type of code out of rack and into rackup in Rack 3. So to the extent that we would consider this, I think it would be in rackup (https://github.com/rack/rackup), not in rack.

I don't think rack should concern itself with this. Applications should provide a config.ru file, and users should run applications by running the appropriate server program that reads the config.ru file. That way, applications are independent of servers and should theoretically run on any rack-compliant server.

It's fine to consider this for rackup though, as rackup is designed to run servers (rack isn't).

[rafaelfranca]

I think this makes sense. I'll move this issue to rackup

[ioquatix]

There is additional work/discussion going on in #38

We could introduce a backwards compatible change to the interface, e.g. Rackup::Config or something like that, and we can feature detect if handlers can support it, e.g. an arity check or handler_class.const_get(:SUPPORTS_CONFIG). Then, we could build a rich interface which supports these use cases more effectively.