Removed my patch in favor of @tenderlove's less invasive approach.

[Aaron Patterson & Jon Moss]

It should not throw a NameError, but should throw a KeyError.

Fixes #26278

When `config.force_ssl` is set to `true`, any POST/PUT/DELETE requests coming in to non-secure url are being redirected with a 301 status.
However, when that happens, the request is converted to a GET request and ends up hitting a different action on the controller.

Since we can not do non-GET redirects, we can instead redirect with a 307 status code instead to indicate to the caller that a fresh request should be tried preserving the original request method.

`rack-ssl` gem which was used to achieve this before we had this middleware directly baked into Rails also used to do the same, ref: https://github.com/josh/rack-ssl/blob/master/lib/rack/ssl.rb#L54

This would be specially important for any apps switching from older version of Rails or apps which expose an API through Rails.

Use ActionDispatch::Request instead of Request because ActionDispatch::Request no longer inherits from Rack::Request.

This allows us to not `||=` in `before_setup`.

In commit fa634484, @tenderlove changed
the behaviour of the way `integration_session` is set up in this object.
It used to be the case that the first time it was accessed, it was
memoized with nil, however, this means that if it had already been set
it was not replaced. After that commit, it is now always set to `nil` in
the execution of `before_setup`.

In RSpec, users are able to invoke `host!` in `before(:all)` blocks,
which execute well before `before_setup` is ever invoked (which happens
in what is equivalent to a `before(:each)` block, for each test. `host!`
causes the integration session to be set up to correctly change the
host, but after fa634484 the
`integration_session` gets overwritten, meaning that users lose their
`host!` configuration (see https://github.com/rspec/rspec-rails/issues/1662).

This commit changes the behaviour back to memoizing with `nil`, as
opposed to directly overwriting with `nil`. This causes the correct
behaviour to occur in RSpec, and unless I'm mistaken will also ensure
that users who want to modify their integration sessions early in rails
will also be able to do so.

Those methods are only using inside this module and by a private method
so they all should be private.

Since e852daa6 only the verb methods
where extracting the defaults options. It was merged a fix for the
`root` method in 31fbbb7f but `match`
was still broken since `:defaults` where not extracted.

This was causing routes defined using `match` and having the `:defaults`
keys to not be recognized.

To fix this it was extracted a new private method with the actual
content of `match` and the `:defaults` extracting was moved to `match`.

Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces

Fix all violations in the repository.

It's tough for people without the knowledge of where the `get` and
friends integration test helpers are defined to find documentation
for them. Add a link to the main integration test documentation.

* Give the section a header to distinguish it from the general doc.
* Replace backticks with + signs to fit SDoc.
* Use double quoted strings.
* Clarify how `parsed_body` works — it doesn't depend on `as` anymore.

fixes error due to Routes#partitioned_routes being removed

When initializing an `ActionDispatch::Http::Headers` object it takes a request object (Rails 5) whereas before it took a hash (Rails 4.x) but the documented example still shows a hash given to the constructor (due to commit 34fa6658) so this is just a documentation change to use the new `from_hash` method introduced in that earlier commit.

At GitHub we need to handle parameter encodings that are not UTF-8. This
patch allows us to specify encodings per parameter per action.

In integration test when specify the "Accept" header with "xhr: true"
option, the Accept header is overridden with a default xhr Accept
header. The issue only affects HTTP header "Accept" but not CGI variable
"HTTP_ACCEPT".

For example:

    get '/page', headers: { 'Accept' => 'application/json' }, xhr: true

    # This is WRONG! And the response.content_type is also affected.
    # It should be "application/json"
    assert_equal "text/javascript, text/html, ...", request.accept
    assert_equal 'text/html', response.content_type

The issue is in `ActionDispatch::Integration::RequestHelpers`. When
setting "xhr: true" the helper sets a default HTTP_ACCEPT if blank.
But the code doesn't consider supporting both HTTP header style and
CGI variable style.

For detail see this GitHub issue:
https://github.com/rails/rails/issues/25859

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

When a `GET` request is sent `as: :json` in an integration test the test
should use Rack's method override to change to a post request so the
paramters are included in the postdata. Otherwise it will not encode the
parameters correctly for the integration test.

Because integration test sets up it's own middleware,
`Rack::MethodOverride` needs to be included in the integration tests as
well.

`headers ||= {}` was moved so that headers are never nil. They should
default to a hash.

Fixes #26033

[Eileen M. Uchitelle & Aaron Patterson]

Fixes #25926

The merging of the 'defaults' option was moved up the stack in e852daa6
This allows us to see where these options originate from the standard
HttpHelpers (get, post, patch, put, delete)

Unfortunately this move didn't incorporate the 'root' method, which has
always allowed the same 'defaults' option before.

Check for any non-UTF8 characters in path parameters at the point they're
set in `env`. Previously they were checked for when used to get a controller
class, but this meant routes that went directly to a Rack app, or skipped
controller instantiation for some other reason, had to defend against
non-UTF8 characters themselves.

The `ActionDispatch::Static` middleware is used low down in the stack to serve
static assets before doing much processing. Since it's called from so low in
the stack, we don't have access to the request ID at this point, and generally
won't have any exception handling defined (by default `ShowExceptions` is added
to the stack quite a bit higher and relies on logging and request ID).

Before https://github.com/rails/rails/commit/8f27d6036a2ddc3cb7a7ad98afa2666ec163c2c3
this middleware would ignore unknown HTTP methods, and an exception about these
would be raised higher in the stack. After that commit, however, that exception
will be raised here.

If we want to keep `ActionDispatch::Static` so low in the stack (I think we do)
we should suppress the `ActionController::UnknownHttpMethod` exception here,
and instead let it be raised higher up the stack, once we've had a chance to
define exception handling behaviour.

This PR updates `ActionDispatch::Static` so it passes `Rack::Request` objects to
`ActionDispatch::FileHandler`, which won't raise an
`ActionController::UnknownHttpMethod` error. If an unknown method is
passed, it should exception higher in the stack instead, once we've had a
chance to define exception handling behaviour.`

Rack [recently](https://github.com/rack/rack/commit/7e7a3890449b5cf5b86929c79373506e5f1909fb)
moved the namespace of its `ParameterTypeError` and `InvalidParameterError`
errors. Whilst an alias for the old name was added, the logic in
`ActionDispatch::ExceptionWrapper` was still broken by this change, since it
relies on the class name.

This PR updates `ActionDispatch::ExceptionWrapper` to handle the Rack 2.0
namespaced errors correctly. We no longer need to worry about the old names,
since Rails specifies Rack ~> 2.0.

Previously we'd only assign a response parser when a request came through
Action Dispatch integration tests. This made calls to `parsed_body` when a TestResponse
was manually instantiated — though own doing or perhaps from a framework — unintentionally
blow up because no parser was set at that time.

The response can lookup a parser entirely through its own ivars. Extract request encoder to
its own file and assume that a viable content type is present at TestResponse instantiation.

Since the default response parser is a no-op, making `parsed_body` equal to `body`, no
exceptions will be thrown.

`config.ssl_options` permits configuring various options for the middleware. Default options for HSTS (specified with the `:hsts` key in the options hash) are specified in `.default_hsts_options`. The documentation did not make clear these defaults, and in one case was wrong.

In Rails 4 these kind of routes used to work:

```ruby
scope '/*id', controller: :builds, as: :build do
  get action: :show
end
```

But since 1a830cbd, routes are only created for
paths specified as strings or symbols. Implicit `nil` paths are just ignored,
with no deprecation warnings or errors. Routes are simply not created. This come
as a surprise for people migrating to Rails 5, since the lack of logs or errors
makes hard to understand where the problem is.

This commit introduces a deprecation warning in case of path as `nil`, while
still allowing the route definition.

When an exception is raised, those Action View rendering logs are just
noise for the end developer. I recently silenced those from Web Console,
as we do use Action View rendering in it as well. It used created a half
a screen of rendering logs. I think we can save those in this recent
push for cleaner development logs.

Now, the silencing is a bit hacky and we have a bunch of it now, so we
can also invest in turning off the logs directly from Action View
objects instead of silencing off the logging stream.

Felt that += overwriting the path variable was a little too hidden.

Make the outcomes easier to spot with an if-else branch.

When running tests with `--enable-frozen-string-literal` or
`# frozen_string_literal: true`, it's currently attempted to mutate the path
string in order to append the format, causing a `RuntimeError`.

```ruby
get '/posts', as: :json
```

```
RuntimeError:
 can't modify frozen String
```

This commit fixes the problem by replacing the mutation with a concatenation,
returning a new string.