Such request can happen on Internet Explorer. When we redirect
after multipart form submission, the request type is changed
to GET, but Content-Type is preserved as multipart. GET request
cannot have multipart body and that caused Rails to fail.
It's similar fix to Rack's one:
8025a4ae94/lib/rack/request.rb (L224)
A callable object passed as a constraint for a route may access the request
parameters as part of its check. This causes the combined parameters hash
to be cached in the environment hash. If the constraint fails then any subsequent
access of the request parameters will be against that stale hash.
To fix this we delete the cache after every call to `matches?`. This may have a
negative performance impact if the contraint wraps a large number of routes as the
parameters hash is built by merging GET, POST and path parameters.
Fixes#2510.
Also if a constraint proc arity is more than one, pass the symbolized path parameters
as the first argument to match redirect proc args and provide easier access.
[#5157 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
* Specify accept-charset on all forms. All recent browsers,
as well as IE5+, will use the encoding specified for form
parameters
* Unfortunately, IE5+ will not look at accept-charset unless
at least one character in the form's values is not in the
page's charset. Since the user can override the default
charset (which Rails sets to UTF-8), we provide a hidden
input containing a unicode character, forcing IE to look
at the accept-charset.
* Now that the vast majority of web input is UTF-8, we set
the inbound parameters to UTF-8. This will eliminate many
cases of incompatible encodings between ASCII-8BIT and
UTF-8.
* You can safely ignore params[:_snowman_]
TODO:
* Validate inbound text to confirm it is UTF-8
* Combine the whole_form implementations in form_helper_test
and form_tag_helper_test
