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 ]
This has similar problems to render file:.
I've never seen this used, and believe it's a relic from when all
templates could be rendered from an absolute path.
The previous behaviour of render file: was essentially the same as
render template:, except that templates can be specified as an absolute
path on the filesystem.
This makes sense for historic reasons, but now render file: is almost
exclusively used to render raw files (not .erb) like public/404.html. In
addition to complicating the code in template/resolver.rb, I think the
current behaviour is surprising to developers.
This commit deprecates the existing "lookup a template from anywhere"
behaviour and replaces it with "render this file exactly as it is on
disk". Handlers will no longer be used (it will render the same as if
the :raw handler was used), but formats (.html, .xml, etc) will still be
detected (and will default to :plain).
The existing render file: behaviour was the path through which Rails
apps were vulnerable in the recent CVE-2019-5418. Although the
vulnerability has been patched in a fully backwards-compatible way, I
think it's a strong hint that we should drop the existing
previously-vulnerable behaviour if it isn't a benefit to developers.
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.
Templates only have one format. Before this commit, templates would be
constructed with a single element array that contained the format. This
commit eliminates the single element array and just implements a
`format` method. This saves one array allocation per template.
This commit is to remove direct access to the "rendered_format"
attribute on the lookup context. "rendered_format" is an implementation
detail that we shouldn't test directly.
This commit passes the mutated source to the template handler as a
parameter and deprecates the old handlers. Old handlers required that
templates contain a reference to mutated source code, but we would like
to make template objects "read only". This change lets the template
remain "read only" while still giving template handlers access to the
source code after mutations.
The AV::Base constructor was too complicated, and this commit tightens
up the parameters it will take. At runtime, AV::Base is most commonly
constructed here:
94d54fa4ab/actionview/lib/action_view/rendering.rb (L72-L74)
This provides an AV::Renderer instance, a hash of assignments, and a
controller instance. Since this is the common case for construction, we
should remove logic from the constructor that handles other cases. This
commit introduces special constructors for those other cases.
Interestingly, most code paths that construct AV::Base "strangely" are
tests.
The test passes an instance of `ActionController::Parameters` that acts
like a Hash but does not respond to some Hash methods like
`symbolize_keys`.
Moreover, if someone were to call `to_h` on the value it would fail since
the parameter is not permitted. So this is a great way to ensure that the
partial rendering pipeline does not mess with `locals`.
This commit removes a deprecated catch-all route in the AV tests. It
defines and includes the necessary routes for each test such that we
don't need the catch-all anymore.
This also helps push us toward #33970
On my local environment execution of `cd actionview/ && bin/test` raises error:
```
(snip)
rails/actionview/test/template/render_test.rb:6:in `<top (required)>': superclass mismatch for class TestController (TypeError)
```
In some test files `TestController` inherited from `ActionController::Base`,
but in `test/actionpack/controller/render_test.rb` file `TestController`
inherited from `ApplicationController`.
This produces error `superclass mismatch for class TestController (TypeError)`
Step to reproduce this on any environment:
`cd actionview/ && bin/test test/template/streaming_render_test.rb test/actionpack/controller/render_test.rb`
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
This test was broken by f650e0324207e46ed5240380e60bdf1e2a5023a6. It was
added by https://github.com/rails/rails/pull/17978, and is adequately
tested elsewhere. The reason that this breaks is that
`Controller#process` is not going to set a new response object, and we
now terminate in callbacks if the response has been sent. The only
reason that this test was calling `get` in the first place was because
the controller under test blows up if `request` was `nil`. The point
being that the failure is invalid, and I don't think we need to fix the
test in this location.
Rails 4.x and earlier didn't support `Mime::Type[:FOO]`, so libraries
that support multiple Rails versions would've had to feature-detect
whether to use `Mime::Type[:FOO]` or `Mime::FOO`.
`Mime[:foo]` has been around for ages to look up registered MIME types
by symbol / extension, though, so libraries and plugins can safely
switch to that without breaking backward- or forward-compatibility.
Note: `Mime::ALL` isn't a real MIME type and isn't registered for lookup
by type or extension, so it's not available as `Mime[:all]`. We use it
internally as a wildcard for `respond_to` negotiation. If you use this
internal constant, continue to reference it with `Mime::ALL`.
Ref. efc6dd550ee49e7e443f9d72785caa0f240def53
This will silence deprecation warnings.
Most of the test can be changed from `render :text` to render `:plain`
or `render :body` right away. However, there are some tests that needed
to be fixed by hand as they actually assert the default Content-Type
returned from `render :body`.
The patched test assumed the file system is case-sensitive, but that is not
necessarily the case. In particular, this test did not pass in the recommended
setup for the dev box, because the /vagrant shared folder is case-insensitive.
After looking at some gems that provide access to file system metadata I have
chosen to go with the check you can see in the patch because, albeit it's a bit
dirty creating a file, it is super easy to understand and clearly portable.
References https://github.com/rails/rails-dev-box/issues/102.
The testing of error messages have been implemented wrongly a few times.
This is an attempt to fix it.
For example, some of these test should have failed with the new code.
The reason they are not failling with the new string is the fact they
were not being tested beforehand.
