aboutsummaryrefslogtreecommitdiffstats
path: root/actionpack/lib/action_dispatch/http/mime_negotiation.rb
Commit message (Collapse)AuthorAgeFilesLines
* allow reseting of request variantsTimo Schilling2014-12-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | The current implementation of `variants=` don't allow a resetting to nil, wich is the default value. This results in the following code smell: ```ruby case request.user_agent when /iPhone/ request.variants = :phone when /iPad/ request.variants = :ipad end ``` With the ability to reset variants to nil, it could be: ```ruby request.variants = case request.user_agent when /iPhone/ :phone when /iPad/ :ipad end ```
* Upgraded rackJarmo Isotalo2014-05-191-3/+9
| | | | | | | | As Rack has some non backwards compatible changes added required modifications to keep behaviour in rails close to same as before. Also modified generators to include rack/rack for not yet released version of rack
* Return null type format when format is not knowRafael Mendonça França2014-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Check if variant array contains only symbolsŁukasz Strzałkowski2014-02-131-2/+2
|
* Variant negotiationLukasz Strzalkowski2014-02-131-2/+4
| | | | | | | | | | | | | | 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
* Move the null mime type to request.formatCarlos Antonio da Silva2013-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TLDR: always return an object that responds to the query methods from request.format, and do not touch Mime::Type[] lookup to avoid bugs. --- Long version: The initial issue was about being able to do checks like request.format.html? for request with an unknown format, where request.format would be nil. This is where the issue came from at first in #7837 and #8085 (merged in cba05887dc3b56a46a9fe2779b6b228880b49622), but the implementation went down the path of adding this to the mime type lookup logic. This unfortunately introduced subtle bugs, for instance in the merged commit a test related to send_file had to be changed to accomodate the introduction of the NullType. Later another bug was found in #13064, related to the content-type being shown as #<Mime::NullType:...> for templates with localized extensions but no format included. This one was fixed in #13133, merged in 43962d6ec50f918c9970bd3cd4b6ee5c7f7426ed. Besides that, custom handlers were not receiving the proper template formats anymore when passing through the rendering process, because of the NullType addition. That was found while migrating an application from 3.2 to 4.0 that uses the Markerb gem (a custom handler that generates both text and html emails from a markdown template). --- This changes the implementation moving away from returning this null object from the mime lookup, and still fixes the initial issue where request.format.zomg? would raise an exception for unknown formats due to request.format being nil.
* Improve a couple exception messages related to variants and mime typesCarlos Antonio da Silva2013-12-031-5/+5
| | | | | Avoid one-liner conditionals when they are too big. Avoid concatenating strings to build error messages. Improve messages a bit.
* Action Pack VariantsŁukasz Strzałkowski2013-12-041-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix formats on xhr requests when HTTP_ACCEPT is empty stringmaximerety2013-03-041-1/+1
| | | | | | Fix ActionDispatch::Request#formats on xhr requests when HTTP_ACCEPT header is empty string. About issue #7774, same fix as in commit bebb02f but for xhr requests.
* Fix ActionDispatch::Request#formats when HTTP_ACCEPT header is empty stringKonstantin Papkovskiy2013-01-171-1/+1
|
* use `_action` instead of `_filter` callbacksFrancesco Rodriguez2012-12-071-2/+2
|
* Add Request#formats=(extensions) that lets you set multiple formats directly ↵David Heinemeier Hansson2012-08-141-0/+21
| | | | in a prioritized order
* Add missing requires in routesBogdan Gusiev2012-04-231-0/+2
|
* Check Accept and Content-Type headers before evaluating them in xhr ↵ogeidix2011-07-191-1/+2
| | | | | | requests. Closes #2119 An xhr request must have an "Accept" or "Content-type" header in order to be considered a request with valid_accept_header.
* Add ignore_accept_header config to AD::Request.José Valim2011-05-021-5/+22
|
* declare regex as a constantNeeraj Singh2010-11-221-1/+3
| | | | Signed-off-by: José Valim <jose.valim@gmail.com>
* do not assume that there is no space betweenNeeraj Singh2010-11-221-1/+1
| | | | | | leading */* and comma Signed-off-by: José Valim <jose.valim@gmail.com>
* current code ignores http header "Accept" if itNeeraj Singh2010-11-221-1/+1
| | | | | | | | | | | has ....,*/* . It is possible to a device to send request such that */* appear at the beginning of the "Accept" header. This patch ensures that "Accept" header is ignored for such cases too. Signed-off-by: José Valim <jose.valim@gmail.com>
* use_accept_header is no longer supportedNeeraj Singh2010-11-211-1/+1
|
* escape constants that should not be linked toJoost Baaij2010-08-271-1/+1
|
* Slightly less annoying check for acceptable mime_types. This allows Accept: ↵Paul Sadauskas2010-04-011-2/+2
| | | | application/json, application/jsonp (and the like), but still blacklists browsers. Essentially, we use normal content negotiation unless you include */* in your list, in which case we assume you're a browser and send HTML [#3541 state:resolved]
* Request#content_type exists in Rack::Request, and other parts of ↵wycats2010-03-281-2/+6
| | | | | | Rack::Request expect it to return a String. Split the Rails API so that Request#content_type returns a String, and Request#content_mime_type returns a Mime::Type object.
* Remove uneeded methods.José Valim2010-03-101-15/+0
|
* Split ActionDispatch http in smaller chunks.José Valim2010-01-161-0/+101