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.

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.

This reverts commit 70d6e16f, reversing
changes made to ea4db3bc.

Seems to be a code merge done by mistake.

any_instance.stubs + unstub with Mocha doesn't restore the original status in the following case,
so we need to undef Customer#to_json before every test

require 'test/unit'
require 'mocha/setup'

module M
  def foo() :foo; end
end

class C
  include M

  undef_method :foo
end

C.any_instance.stubs(:foo).returns(:mocha)

C.any_instance.unstub(:foo)

Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in

    https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d

we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.

In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.

Rails includes a single character body to a head(:no_content) response to work around an old Safari bug where headers were ignored if no body sent.

This patch brings the behavior slightly closer to spec if :no_content/204 is explicity requested via a head only response.

Status comparison done on symbolic and numeric values

Not returning any content when responding with head and limited to a status code that explicitly states no content will be returned - 100..199, 204, 205, 304.

Assuming the type ":touch", Collector.new was calling
send(:touch), which instead of triggering method_missing
and generating a new collector method, actually
invoked the private method `touch` inherited from
Object.

By generating the method for each mime type as it
is registered, the private methods on Object can
never be reached by `send`, because the `Collector`
will have them before `send` is called on it.

To do this, a callback mechanism was added to Mime::Type

This allows someone to add a callback for whenever
a new mime type is registered. The callback then
gets called with the new mime as a parameter.

This is then used in AbstractController::Collector
to generate new collector methods after each mime
is registered.

Raise a rescuable exception when Rails doesn't know what to do with the format, rather than responding with a head :not_acceptable (406)

In the current router DSL, using the +match+ DSL
method will match all verbs for the path to the
specified endpoint.

In the vast majority of cases, people are
currently using +match+ when they actually mean
+get+. This introduces security implications.

This commit disallows calling +match+ without
an HTTP verb constraint by default. To explicitly
match all verbs, this commit also adds a
:via => :all option to +match+.

Closes #5964

PATCH is the correct HTML verb to map to the #update action. The
semantics for PATCH allows for partial updates, whereas PUT requires a
complete replacement.

Changes:
* adds config.default_method_for_update you can set to :patch
* optionally use PATCH instead of PUT in resource routes and forms
* adds the #patch verb to routes to detect PATCH requests
* adds #patch? to Request
* changes documentation and comments to indicate support for PATCH

This change maintains complete backwards compatibility by keeping :put
as the default for config.default_method_for_update.

Default responder was only using the given respond block when user
requested for HTML format, or JSON/XML format with valid resource. This
fix the responder so that it will use the given block regardless of the
validity of the resource. Note that in this case you'll have to check
for object's validity by yourself in the controller.

Fixes #4796

Responders now return 204 No Content for API requests without a response body (as in the new scaffold)

This fixes the problem of having a non-explicit message when the :location option is not provided in respond_with.

Fixed while traveling to heuruko

After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.

It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.

There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

when using respond_with with an invalid resource and custom options, the default response status and error messages should be returned
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

If a user wants json output then try best to render json output. In such cases prefer kind_of(String) over respond_to?(to_str)

[#5841 state:resolved]
Signed-off-by: NJosé Valim <jose.valim@gmail.com>