* remove setting quiet requests inside puma rack handler
* added test cases for user and file config of log_requests
* update test cases to use example files
Co-authored-by: Nate Berkopec <nate.berkopec@gmail.com>
This work starts the effort of removing connected_port from the specs.
I have moved the code around a bit to get all connected_ports, the tests seem
to pass in the appropriate areas.
I want to verify this path before attempting to remove all UniquePort calls in
the tests.
This issue is somewhat tricky. When Rails is booted via `rails server` there are two types of configuration options passed, ones specified directly by a user like `rails s -p 3001` will always "win".
For any other config that is not explicitly passed in, puma will consider it a "default". For example when you run `rails s` (without -p) then the default port will be 3000.
There is one other way to configure puma though, and that is via a config file:
```
# config/puma.rb
port 3002
```
This is the order of precedence for configuration
1) Anything the user explicitly passes to `rails s`
2) Config specified in `config/puma.rb` file
3) Default values passed in via `rails s`
4) Defaults values stored in puma
This fallback mechanism works well except in the case of calling `port` in a `config/puma.rb` file. To understand look at the [old method definition](2668597ec1/lib/puma/dsl.rb (L140-L145)):
```
def port(port, host=nil)
host ||= Configuration::DefaultTCPHost
bind "tcp://#{host}:#{port}"
end
```
When the `port` method gets called, even if the user did not specify a `host` the `Configuration::DefaultTCPHost` will be used, which is a problem for local development because it defaults to `0.0.0.0`. [SO about 0.0.0.0 versus localhost](https://stackoverflow.com/questions/20778771/what-is-the-difference-between-0-0-0-0-127-0-0-1-and-localhost).
In this case, while a user did directly specify a port, they did not specify a host, so you would expect the `rails s` defaults passed in to take affect.
To make Puma respect that the host coming from `rails s` has more precedence than it's own default host, we must introduce the ability to set and retrieve a default_host value.
This is then used in the rack handler so when `rails s` passes in `:Host => "localhost"` then it is used instead of reverting to `0.0.0.0`.
The issue with #1699 is the test was wrong, it would have failed if a config file was present with a `port` invocation.
The "default" configuration puma level is initialized with a "binds" of `tcp://0.0.0.0:9292`. Puma is designed to be able to bind to multiple ports.
When a `:port` is sent from Rails along with an empty `user_supplied_options` then the port is treated as a "default". This is merged in with the system defaults, and then later converted into a "binds" via calling `config.port` in the `set_host_port_to_config` method.
The bug comes due to the "level" of the configuration. Since both are being set on the same "level" the `port` call does not over-write the existing binds but instead prepends to the array. We can fix by ensuring that any binds in a given "level" are empty before setting it.
running `rake` loads all files starting with `test_` which is not supposed to also load the helper,
since the helper should be loaded by each test and is not a test itself.
To build a "binds" we need a host IP (via Host) and a port. We were running into a problem where a Host was being explicitly set via user but the Port was being defaulted to by Rails. When this happened the Host was used, but Puma would accidentally use it's own default port 9292 instead of Rail's port of 3000.
The fix was to use the "default" port passed in from a framework (if available) when no explicitly set Port is provided.
When options are passed to the Puma rack handler it is unknown if the options were set via a framework as a default or via a user. Puma currently has 3 different sources of configuration, the user via command line, the config files, and defaults.
Rails 5.1+ will record the values actually specified by the user versus the values specified by the frameworks. It passes these values to the Rack handler and now it's up to Puma to do something with that information.
When only framework defaults are passed it will set
```
options[:user_supplied_options] = []
```
When one or more options are specified by the user such as `:Port` then those keys will be in the array. In that example it will look like this
```
options[:user_supplied_options] = [:Port]
```
This change is 100% backwards compatible. If the framework is older and does not pass this information then the `user_supplied_options` will not be set, in that case we assume all values are user supplied.
Internally we accomplish this separation by replacing `LeveledOptions` which was a generic way of specifying options with different priorities with a more explicit `UserFileDefaultOptions` this assumes only 3 levels of options and it will use them in the order supplied (user config wins over file based config wins over defaults).
Now instead of using 1 dsl to set all values, we use 3. A user dsl, a file dsl and a Configuration.new` will return all 3 DSLs to the block. It's up to the person using the block to use the correct dsl corresponding to the source of data they are getting.
* Bump minitest version.
* Add basic test helper file.
* Use minitest for web server tests.
* Use Minitest for unix socket tests.
* Use Minitest for ThreadPool tests.
* Use Minitest for TCP-Rack tests
* Use Minitest for TCPLogger tests.
* Add missing helper to test helpers.
* Use Minitest for Rack server tests.
* Use Minitest for Rack handler tests.
* Use Minitest for Puma::Server tests.
* Use Minitest for Puma::Server with SSL tests.
* Use Minitest for persisten connections tests.
* Require puma in test_helper file.
* Use minitest for Puma::NullIO tests.
* Remove unnecessary requires on test files.
* Use Minitest for MiniSSL tests.
* Use Minitest for IOBuffer tests.
* Require bundler/setup in Rakefile.
* Use Minitest for HttpParser tests.
* Use Minitest for Puma::Configuration tests.
* Use Minitest for Puma::CLI tests.
* Bump Minitest version for Ruby 2.1 Gemfile.
* Use Minitest for integration tests.
* Use Minitest for Puma::App::Status tests.
* Remove test-unit from Gemfiles.
* Add timeout helper to Minitest::Test.
* Use Minitest for Puma::Binder tests.
* Remove testhelp file.
* Add missing require to Puma::Binder tests.
* Prefer require instead of require_relative.
