| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Conceptually revert #20276
The feature was implemented for the `responders` gem. In the end,
they did not need that feature, and have found a better fix (see
plataformatec/responders#131).
`ImplicitRender` is the place where Rails specifies our default
policies for the case where the user did not explicitly tell us
what to render, essentially describing a set of heuristics. If
the gem (or the user) knows exactly what they want, they could
just perform the correct `render` to avoid falling through to
here, as `responders` did (the user called `respond_with`).
Reverting the patch allows us to avoid exploding the complexity
and defining “the fallback for a fallback” policies.
2. `respond_to` and templates are considered exhaustive enumerations
If the user specified a list of formats/variants in a `respond_to`
block, anything that is not explicitly included should result
in an `UnknownFormat` error (which is then caught upstream to
mean “406 Not Acceptable” by default). This is already how it
works before this commit.
Same goes for templates – if the user defined a set of templates
(usually in the file system), that set is now considered exhaustive,
which means that “missing” templates are considered `UnknownFormat`
errors (406).
3. To keep API endpoints simple, the implicit render behavior for
actions with no templates defined at all (regardless of formats,
locales, variants, etc) are defaulted to “204 No Content”. This
is a strictly narrower version of the feature landed in #19036 and
#19377.
4. To avoid confusion when interacting in the browser, these actions
will raise an `UnknownFormat` error for “interactive” requests
instead. (The precise definition of “interactive” requests might
change – the spirit here is to give helpful messages and avoid
confusions.)
Closes #20666, #23062, #23077, #23564
[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
|
|
|
|
|
| |
Variants are typically set in the controller based on some attribute of
the request that the browser sent. We should make our tests more in
line with reality by doing the same and not mutating the request object.
|
|
|
|
|
|
|
|
|
|
| |
In 0de4a23 the behavior when there is a missing template was changed to
not raise an error, but instead head :no_content. This is a breaking
change and some gems rely on this happening.
To allow gems and other code to work around this, allow
`default_render` to take a block which, if provided, will
execute the contents of that block instead of doing the `head :no_content`.
|
|
|
|
|
|
|
|
|
| |
After merging #19377 ActionPack tests were missing a require for
`ActiveSupport::LogSubscriber::TestHelper` and change didn't take
into account that logger could be nil. Added the require and only log to
info if logger exists.
This wasn't caught earlier because these tests only run after a merge.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
in `ActionController::TestCase` and
`ActionDispatch::Integration`
Old syntax:
`xhr :get, :create, params: { id: 1 }`
New syntax example:
`get :create, params: { id: 1 }, xhr: true`
|
|
|
|
|
|
|
|
| |
Non-kwargs requests are deprecated now.
Guides are updated as well.
`post url, nil, nil, { a: 'b' }` doesn't make sense.
`post url, params: { y: x }, session: { a: 'b' }` would be an explicit way to do the same
|
|
|
|
| |
This functionality has been extracted to the responders gem.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
respond_with (and consequently the class-level respond_to)
are being removed from Rails. Instead of moving it to a 3rd
library, the functionality will be moved to responders gem
(at github.com/plataformatec/responders) which already provides
some responders extensions.
|
|
|
|
|
|
| |
Adds a comment before JSONP callbacks. See
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/ for more
details on the exploit in question.
|
|
|
|
|
|
|
| |
The controller can set the response format as 'JSON' before the renderer code be
evaluated, so we must replace it when necessary.
Fixes #15081
|
|\
| |
| | |
Un-define :to_json for Customer class after stubbing.
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When requesting a controller with the following code with a unknown format:
def my_action
respond_to do |format|
format.json { head :ok }
format.any { render text: 'Default response' }
end
end
we should render the default response instead of raising ActionController::UnknownFormat
Fixes #14462
Conflicts:
actionpack/CHANGELOG.md
actionpack/test/controller/mime/respond_with_test.rb
Conflicts:
actionpack/CHANGELOG.md
|
|
|
|
| |
defined (just like any other variant)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow setting `request.variant` as an array - an order in which they will be
rendered.
For example:
request.variant = [:tablet, :phone]
respond_to do |format|
format.html.none
format.html.phone # this gets rendered
end
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like `format.any`, you can do the same with variants.
It works for both inline:
respond_to do |format|
format.html.any { render text: "any" }
format.html.phone { render text: "phone" }
end
and block syntax:
respond_to do |format|
format.html do |variant|
variant.any(:tablet, :phablet){ render text: "any" }
variant.phone { render text: "phone" }
end
end
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, when setting variant specific code, you're not sharing any code
within format.
Inline syntax can vastly simplify defining variants in those situations:
respond_to do |format|
format.js { render "trash" }
format.html do |variant|
variant.phone { redirect_to progress_path }
variant.none { render "trash" }
end
end
Becomes:
respond_to do |format|
format.js { render "trash" }
format.html.phone { redirect_to progress_path }
format.html.none { render "trash" }
end
|
|
|
|
|
|
|
| |
little more work!
This reverts commit 186161148a189839a1e0924043f068a8d155ce69, reversing
changes made to cad9eb178ea5eec0e27d74e93518f4ed34e2f997.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, when setting variant specific code, you're not sharing any code
within format.
Inline syntax can vastly simplify defining variants in those sitiations:
respond_to do |format|
format.js { render "trash" }
format.html do |variant|
variant.phone { redirect_to progress_path }
variant.none { render "trash" }
end
end
`
Becomes:
respond_to do |format|
format.js { render "trash" }
format.html.phone { redirect_to progress_path }
format.html.none { render "trash" }
end
|
|
|
|
| |
controller
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, variants in the templates will be picked up if a variant is set
and there's a match. The format will be:
app/views/projects/show.html.erb
app/views/projects/show.html+tablet.erb
app/views/projects/show.html+phone.erb
If request.variant = :tablet is set, we'll automatically be rendering the
html+tablet template.
In the controller, we can also tailer to the variants with this syntax:
class ProjectsController < ActionController::Base
def show
respond_to do |format|
format.html do |html|
@stars = @project.stars
html.tablet { @notifications = @project.notifications }
html.phone { @chat_heads = @project.chat_heads }
end
format.js
format.atom
end
end
end
The variant itself is nil by default, but can be set in before filters, like
so:
class ApplicationController < ActionController::Base
before_action do
if request.user_agent =~ /iPad/
request.variant = :tablet
end
end
end
This is modeled loosely on custom mime types, but it's specifically not
intended to be used together. If you're going to make a custom mime type,
you don't need a variant. Variants are for variations on a single mime
types.
|
|
|
|
|
|
|
|
| |
This fixes an issue where the respond_with worked directly with the given
options hash, so that if a user relied on it after calling respond_with,
the hash wouldn't be the same.
Fixes #12029
|
|
|
|
| |
This interface should be use when implementing renderers.
|
|
|
|
|
|
|
|
|
|
|
|
| |
renderer is available.
Currently if a user calls #respond_with(csvable), but has not csv
renderer available, Responder will just run through the default render
behavior twice, raising ActionView::MissingTemplate both times.
This changes ActionController::Metal::Responder#api_behavior to check
in advance whether there is a renderer available, and raise
ActionController::MissingRenderer if not.
|
|
test files.
|