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.
This middleware has been logging at a FATAL level since the first
[commit][1] in Rails (the code originally lived in
actionpack/lib/action_controller/rescue.rb). However, FATAL is
documented in the Ruby Logger [docs][2] as being for "An unhandleable
error that results in a program crash.", which does not really apply to
this case since DebugExceptions is handling the error. A more
appropriate level would be ERROR, which the Ruby Logger docs describe as
"A handleable error condition."
This commit introduces a new configuration for the DebugExceptions log
level so that new apps will have it set to ERROR by default and ERROR
can eventually be made the default.
[1]: db045dbbf60b53dbe013ef25554fd013baf88134
[2]: https://ruby-doc.org/3.2.1/stdlibs/logger/Logger/Severity.html
Background
----------
During integration tests, it is desirable for the application to respond
as closely as possible to the way it would in production. This improves
confidence that the application behavior acts as it should.
In Rails tests, one major mismatch between the test and production
environments is that exceptions raised during an HTTP request (e.g.
`ActiveRecord::RecordNotFound`) are re-raised within the test rather
than rescued and then converted to a 404 response.
Setting `config.action_dispatch.show_exceptions` to `true` will make the
test environment act like production, however, when an unexpected
internal server error occurs, the test will be left with a opaque 500
response rather than presenting a useful stack trace. This makes
debugging more difficult.
This leaves the developer with choosing between higher quality
integration tests or an improved debugging experience on a failure.
I propose that we can achieve both.
Solution
--------
Change the configuration option `config.action_dispatch.show_exceptions`
from a boolean to one of 3 values: `:all`, `:rescuable`, `:none`. The
values `:all` and `:none` behaves the same as the previous `true` and
`false` respectively. What was previously `true` (now `:all`) continues
to be the default for non-test environments.
The new `:rescuable` value is the new default for the test environment.
It will show exceptions in the response only for rescuable exceptions as
defined by `ActionDispatch::ExceptionWrapper.rescue_responses`. In the
event of an unexpected internal server error, the exception that caused
the error will still be raised within the test so as to provide a useful
stack trace and a good debugging experience.
This lets us remove the reference to DebugExceptions from the Action
Dispatch railtie, which was causing load order issues since it depends
on ActionDispatch::Request.
As of Ruby 2.7 DidYouMean is included as a default gem, so there is no
need to check if DidYouMean is defined in the test suite. We still need
to check if the DidYouMean modules are defined in the actual code, as
someone might run Rails with DidYouMean disabled by using the
`--disable-did_you_mean` flag. This is ussually done for performance
reasons.
This commit also includes some of the changes made by Yuki in:
https://github.com/rails/rails/pull/39555
These changes include replacing Jaro with the more accurate
SpellChecker, and using DidYouMean::Correctable for simplere
corrections.
The DidYouMean::SpellChecker does have a treshold for corrections.
If there is not enough similarity it might not return a suggestion.
To stop the tests from failing some test data had to be changed.
For example, `non_existent` does not meet the treshold for `hello`, but
`ello` does:
DidYouMean::SpellChecker.new(dictionary: %w[hello]).correct('non_existent')
=> []
DidYouMean::SpellChecker.new(dictionary: %w[hello]).correct('ello')
=> ["hello"]
The treshold makes sense for spelling errors. But maybe we should add a
different SpellChecker that helps to get a suggestion even if there is
little overlap. For example for when a model only has 2 attributes
(title and body), it's helpful to get a suggestion for `name`
Co-Authored-By: Yuki Nishijima <yk.nishijima@gmail.com>
To be able to distinguish from other kinds of `Mime::Type::InvalidMimeType` that may be raised by user or third-party code. It's only failure in parsing client-supplied content-types in ActionDispatch::Http::MimeNegotiation that should result in special handling.
This also allows third-party error handling/tracking code to specifically target the new `ActionDispatch::Http::MimeNegotiation::InvalidType` for ignoring or other special handling, separate from `Mime::Type::InvalidMimeType`
This is a revision of #35753 in response to #37620 and discussion with @eugeneius
This reverts commit 2eb7aa111bbbf69fe89bdcd96b4839480e2ac076, reversing
changes made to 0b28f0c39c5b0a0009f1ea9d13ce97704e20c85b.
Rails backtrace cleaner needs to be able to return empty traces to
separate application code from the framework code and not report
exceptions that happen inside only framework code.
See
345de17caf/actionpack/lib/action_dispatch/middleware/exception_wrapper.rb (L72).
Happy to squash this before merge. Just separate so I can whittle
these down.
Most of the problem seems to be centered around the backtrace filter
being both for general use and for minitest... and I'm only aware of /
addressing minitest issues.
If they really need to be separate, then we can make a separate one
for minitest.
Before 2169bd3d2a9d2f331a5dd6e41d9d638e0da6117c, a template's source was
encoded in place when it was compiled, and the `source_extract` method
could rely on `Template#source` to return a properly encoded string.
Now that `Template#source` always returns a new copy of the template
source with no encoding, `source_extract` should call `encode!` itself.
The issue was reported in #29537. We expect Exception#annoted_source_code
to return an `Array`, but this contract may not be followed by all the
implementers.
Fixes#29537.
Since #35709, `Response#conten_type` returns only MIME type correctly.
It is a documented behavior that this method only returns MIME type, so
this change seems appropriate.
39de7fac05/actionpack/lib/action_dispatch/http/response.rb (L245-L249)
But unfortunately, some users expect this method to return all
Content-Type that does not contain charset. This seems to be breaking
changes.
We can change this behavior with the deprecate cycle.
But, in that case, a method needs that include Content-Type with
additional parameters. And that method name is probably the
`content_type` seems to properly.
So I changed the new behavior to more appropriate `media_type` method.
And `Response#content_type` changed (as the method name) to return Content-Type
header as it is.
Fixes#35709.
[Rafael Mendonça França & Yuuji Yaginuma ]
Each time a missing route is hit 32 lines of internal rails traces
are written to the log. This is overly verbose and doesn't offer
any actionable information to the user.
With this change we'll still write an error message showing the
route error but the trace will be omitted.
- https://github.com/rails/rails/pull/35604 introduced a vulnerability fix
to raise an error in case the `HTTP_ACCEPT` headers contains malformated
mime type.
This will cause applications to throw a 500 if a User Agent sends an
invalid header.
This PR adds the `InvalidMimeType` in the default `rescue_responses` from
the ExceptionWrapper and will return a 406. I looked up the HTTP/1.1
RFC and it doesn't stand what should be returned when the UA
sends malformated mime type. Decided to get 406 as it seemed to be the
status the better suited for this.
This commit ensures that locals are passed in to the template objects
when they are constructed, then removes the `locals=` mutator on the
template object. This means we don't need to mutate Template objects
with locals in the `decorate` method.
There are two cases where the debug view does not show the error details
properly:
* When the cause is mapped to an HTTP status code the last exception is
unexpectedly uwrapped
* When the last error is thrown from a view template the debug view is
not using the `rescues/template_error.html.erb` to generate the view
Both the cases could be fixed by not unwrapping the exception. The only
case where the exception should be unwrapped is when the last error is
an `ActionView::Template::Error` object. In this case the HTTP status
code is determined based on the cause.
There are actually more wrapper exceptions that are intentionally
thrown. However, there is a consistent pattern of setting the original
message and original backtrace to the wrapper exception implemented, so
the debug view will not lose the information about what went wrong
eariler.
In this case statement, there are two patterns that start with the same
line:
when %r{/not_found}
...
when %r{/not_found_original_exception}
...
Because the string "/not_found_original_exception" does match the first
one, it is never routed to what it is supposed to be routed, causing one
of the tests for DebugExceptions to happen to be passing.
After changing the regex expressions back to strings, I noticed that the
test setup is not complete (the template object needs to be a proper
template object). Once I fixed it all the tests started padding.
Plugins interacting with the exceptions caught and displayed by
ActionDispatch::DebugExceptions currently have to monkey patch it to get
the much needed exception for their calculation.
With DebugExceptions.register_interceptor, plugin authors can hook into
DebugExceptions and process the exception, before being rendered. They
can store it into the request and process it on the way back of the
middleware chain execution or act on it straight in the interceptor.
The interceptors can be play blocks, procs, lambdas or any object that
responds to `#call`.
I have been seeing people setting `Logger` instances for `config.logger`
and it blowing up on `rails/web-console` usage.
Now, I doubt many folks are manually setting `ActionView::Base.logger`,
but given that `DebugExceptions` is running in a pretty fragile
environment already, having it crash (and being silent) in those cases
can be pretty tricky to trace down.
I'm proposing we verify whether the `ActionView::Base.logger` supports
silencing before we try to do it, to save us the headache of tracing it
down.
