Repository navigation
Feature: Standardize an API for Rack Handler to distinguish between user specified and default options #39
Description
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
Activity
jeremyevans commentedon Oct 4, 2025
We moved this type of code out of
rackand intorackupin Rack 3. So to the extent that we would consider this, I think it would be inrackup(https://github.com/rack/rackup), not inrack.I don't think
rackshould concern itself with this. Applications should provide aconfig.rufile, and users should run applications by running the appropriate server program that reads theconfig.rufile. That way, applications are independent of servers and should theoretically run on any rack-compliant server.It's fine to consider this for
rackupthough, asrackupis designed to run servers (rackisn't).rafaelfranca commentedon Oct 6, 2025
I think this makes sense. I'll move this issue to rackup
ioquatix commentedon Oct 7, 2025
There is additional work/discussion going on in #38
We could introduce a backwards compatible change to the interface, e.g.
Rackup::Configor something like that, and we can feature detect if handlers can support it, e.g. an arity check orhandler_class.const_get(:SUPPORTS_CONFIG). Then, we could build a rich interface which supports these use cases more effectively.