This adds additional test coverage to ShowExceptions, since one of the
possible responses it creates was not previously tested. Because of the
previous [addition][1] of Rack::Lint, this also demonstrates that the
Content-Type header needed to be fixed.
[1]: 339dda4a82356d173b62dab144870790618e40c6
The naming difference between the test harness' [file_fixture][] helper
made available through Active Support (along with the
`file_fixture_path` configuration value) and the integration test
harness' [fixture_file_upload][] is a constant source of confusion and
surprise.
Since Active Support is more ubiquitous, this commit renames the
`fixture_file_upload` method to `file_fixture_upload` to match the order
of words in `file_fixture` and `file_fixture_path`.
To preserve backwards compatibility, declare a `fixture_file_upload`
alias to be preserved into the future (or removed at a future point in
time).
[file_fixture]: https://edgeapi.rubyonrails.org/classes/ActiveSupport/Testing/FileFixtures.html#method-i-file_fixture
[fixture_file_upload]: https://edgeapi.rubyonrails.org/classes/ActionDispatch/TestProcess/FixtureFile.html#method-i-fixture_file_upload
As of Selenium 4.6, [the Selenium Manager is capable of managing Chrome
Driver installations and integrations][readme]. As of Selenium 4.11, the
Selenium Manager is capable of [capable of resolving the Chrome for
Testing installation][] path.
By omitting the `gem` declaration from the `Gemfile.tt`, newly generated
applications and applications updating their `Gemfile` in lockstep with
newer Rails versions can shed the dependency and avoid test failures
introduced by newly released Chrome versions (like, for example,
[titusfortner/webdrivers#247][]).
[readme]: 43f8ac436c (update-selenium-manager)
[titusfortner/webdrivers#247]: https://github.com/titusfortner/webdrivers/issues/247
[capable of resolving the Chrome for Testing installation]: https://github.com/rails/rails/pull/48847#issuecomment-1656756862
Co-authored-by: Titus Fortner <titusfortner@users.noreply.github.com>
This wraps test coverage for `ActionDispatch::ShowExpections` in
`Rack::Lint` middleware in order to validate that both
`ActionDispatch::ShowExceptions` and `ActionDispatch::PublicExceptions`
conform to the Rack SPEC.
It also ensures that the response headers returned by the *Exceptions
middleware respect casing (mixed case for Rack 2, lower case for Rack 3)
This adds additional test coverage to DebugExceptions to validate that
its behavior conforms to the Rack SPEC.
The only changes necessary were to use dynamic header casing for
Content-Type and Content-Length
This commit changes the router to use the expected casing for the
x-cascade header: in Rack 2, this is mixed-case, and in Rack 3, this is
lower case.
This also fixes https://github.com/rails/rails/issues/47096.
Rack 3 now allows response header values to be an Array when handling
multiple values. Newline encoded headers are no longer supported.
This commit updates `ActionDispatch::SSL#flag_cookies_as_secure!` to
be Rack-3 compliant by setting the `set-cookie` header to an Array
rather than a newline-separated String if the current Rack version is
3+.
Additionally, this commit adds `Rack::Lint` to the Rack app in the
middleware test suite so that we can ensure all of the tests are
compliant with the Rack SPEC.
In both Rack 2 and Rack 3, all headers must be strings. SERVER_PORT has
an additional requirement that it must be an Integer (represented as a
string).
When using #port= on a TestRequest, the value passed has been coerced
into an integer since it was [introduced][1]. Since this is explicitly
incorrect per both Rack 2 and Rack SPEC, the coercion is removed.
This does have the potential to change the value for users who are
checking TestRequest#headers directly, but if they are using
Request#port the value will not change because #port also coerces values
to ints.
[1]: 61960e7b37767140e9af68bd5373e06dce08492d
To ensure Rails is and remains compliant with [the Rack 3
spec](6d16306192/UPGRADE-GUIDE.md)
we can add `Rack::Lint` to the Rails middleware tests.
This adds additional test coverage to `ActionDispatch::ServerTiming` to
validate that its input and output follow the Rack SPEC.
The `Server-Timing` header definition was moved to
`ActionDispatch::Constants` and is now downcased to match the Rack 3
SPEC.
The tests that rely on a `Concurrent::CyclicBarrier` ("events are
tracked by thread") were changed since passing the required proc in the
env is not compatible with the SPEC:
```
Rack::Lint::LintError: env variable proc has non-string value
```
The same can be achieved by invoking the proc as a child Rack app.
This adds additional test coverage to HostAuthorization to validate that
its behavior conforms to Rack SPEC.
This fixes the following two issues in the reponse returned by
DebugLocks:
- Rack::Lint::Error: uppercase character in header name
Content-{Type/Length}
- Rack::Lint::Error: a header value must be a String or Array of
Strings, but the value of 'content-length' is an Integer
This adds additional test coverage to Static to validate that its
behavior conforms to the Rack SPEC.
The test changes are just downcasing headers where appropriate:
- the Static `headers` params is purely user configured headers, so its
reasonable to expect these shoud be correct for an application's Rack
version
- header assertions can use downcased headers because Rack::MockRequest
returns a Rack::Response, which uses Rack::Headers internally (so
either casing will work)
Additionally, the unconditionally downcased headers in the Static
middleware were updated to be conditional based on the Rack version to
ensure that this middleware remains fully compatible with other Rack 2
middleware.
This adds additional test coverage to PermissionsPolicy::Middleware to
validate that it conforms to the Rack SPEC.
The only changes necessary were to use the appropriate header casing for
Content-Type and Feature-Policy. Since this was the only usage of the
CONTENT_TYPE constant, I opted to remove it, but I can replace it with a
DeprecatedConstantProxy if that's more desirable.
This adds additional test coverage to ActionableExceptions to validate
that its behavior conforms to the Rack SPEC.
The changes neccesary were to ensure that Response headers are downcased
when using Rack 3. For Content-Type and Content-Length, this is trivial
because Rack provides constants who's casing is dependent on the version
(Rack 2 is mixed, and Rack 3 is downcased). Since Rack does not include
a LOCATION constant, the Response::LOCATION constant was updated to
have a downcased value when using Rack 3.
Additionally, there was some missing coverage for invalid redirect URLs
which was addressed as well.
This adds additional test coverage to HostAuthorization to validate that
its behavior conforms to the Rack SPEC.
By using Rack:: constants for Content-Type and Content-Length, we are
able to use the "correct" versions of the headers for applications using
each Rack version.
Additionally, two tests had to be updated that use an ipv6 address
without brackets in the HOST header because Rack::Lint warned that these
addresses were not valid HOST values. Rack::Lint checks HOST headers using
`URI.parse("http://#{HOST}/")`, and from what I could find, this
requirement follows RFC 3986 Section 3.2.2:
```
host = IP-literal / IPv4address / reg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
```
To ensure Rails is and remains compliant with [the Rack 3
spec](6d16306192/UPGRADE-GUIDE.md)
we can add `Rack::Lint` to the Rails middleware tests.
There was no test file for ActionDispatch::AssumeSSL, so this change
adds one and validating that its input and output follow the Rack SPEC.
When development tools try to load Rails components, they sometimes end up loading files that will error out since a dependency is missing. In these cases, the tooling can catch the error and change its behaviour.
However, since the warning is printed directly to `$stderr`, the tooling cannot catch and suppress it easily, which ends up causing noise in the output of the tool.
This change makes Rails print these warnings using `Kernel#warn` instead, which can be suppressed by the tooling.
