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)
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::RemoteIp` to validate that its input and
output follow the Rack SPEC.
The only code testing this middleware are the ones for
`ActionDispatch::Request`.
Several changes were required to make the tests pass:
- `CONTENT_LENGTH` must be a string
- `SERVER_PORT` must be a string
- `HTTP_HOST` must be a string
- `rack.input` must be an IO object, with ASCII-8BIT encoding
- By leveraging `Rack::MockRequest`, we can pass the symbol :input,
and the string value, and it will be converted to an IO object
with the correct encoding.
- See [definition here](444dc8a130/lib/rack/mock_request.rb (L89-L97))
- using `Rack::MockRequest` also means that any symbol keys being passed
to setup the env, will be discarded. [Only string keys are copied.]444dc8a130/lib/rack/mock_request.rb (L156)
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 RequestId to validate that its
input and output follow the Rack SPEC.
In this case, the only changes necessary were to the Request tests. This
is due to the fact that the Request and Response tests use different
classes for their Response headers. The Response tests simulate a Rails
app, where the Response headers will be a Rack::Headers object for
compatbility with both Rack 2 and 3. However, since the Request tests
are only using the Hash returned by the test app, the tests must use a
downcased header to support both Rack 2 and Rack 3.
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.
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::MiddlewareStack` to validate that its input and output follow the Rack SPEC.
In this case, no changes are required, and the additional test
will ensure this middleware remains compliant with the Rack SPEC.
This commit refactors the StaticTests class in preparation for adding
Rack::Lint to the tests.
The first change is inlining the StaticTests module into the StaticTest
class. It was originally extracted into a module when Static was
[changed][1] to support passing multiple root paths, but support for
multiple paths has since been [removed][2].
The second change is to move all Rack App creation into a single method.
This will make it extremely easy to add Rack::Lint to the App in a
followup commit.
[1]: 401cd97923fb52c8f8c458b8cb276b338e0b20f3
[2]: d5ad92ced1786b742c3ecce3cb60d851c7200bc9
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::Executor` to
validate that its input and output follow the Rack SPEC.
This also removes some tests that were asserting the body object
passed to `ActionDispatch::Executor` and not the Rack SPEC.
See also https://github.com/rack/rack/issues/2100.
This adds an additional test to the ActionDispatch::Cookies middleware
test suite to ensure that the middleware sets the expected cookie header
when the request contains a cookie jar. Additionally, the test wraps the
Cookies middleware in Rack::Lint to ensure that ActionDispatch::Cookies
complies with the Rack SPEC.
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.
This adds additional test coverage for ActionDispatch::Callbacks by
validating that its input and output follow the Rack SPEC.
The `"rack.input" => StringIO.new("")` header value raised the following error:
```
Rack::Lint::LintError: rack.input #<StringIO:0x00007fd7513fe550> does not have ASCII-8BIT as its external encoding
```
Since this header is not required for the test, it is now removed.
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.
