aboutsummaryrefslogtreecommitdiffstats
path: root/actionpack/lib/action_dispatch/http/mime_negotiation.rb
Commit message (Collapse)AuthorAgeFilesLines
* Remove last uses of `@env[]` and `@env[]=`Jon Moss2016-04-281-1/+1
| | | | | | | | | Last August (2015), @tenderlove worked to remove all `@env[]` and `@env[]=`, in favor of using `set_header`, `get_header`, etc. (Here's an [example commit](https://github.com/rails/rails/commit/f16a33b68efc3dc57cfafa27651b9a765e363fbf)). This PR should remove the last uses of these methods, and fully convert them to the newly standardized API.
* Format from Accept headers have higher precedence than path extension formatJorge Bejar2015-12-291-2/+2
|
* Rely on default Mime format when MimeNegotiation#format_from_path_extension ↵Jorge Bejar2015-12-291-3/+3
| | | | | | is not a valid type Closes #22747
* Avoid calling AD::MimeNegotiation#format_from_path_extension method twiceJorge Bejar2015-12-091-2/+2
|
* Do not add format key to request_paramsJorge Bejar2015-12-091-0/+9
| | | | | | | | | I did this change but it is affecting how the request params end up after being processed by the router. To be in the safe side, I just take the format from the extension in the URL when is not present in those params and it's being used only for the `Request#formats` method
* Use `Mime[:foo]` instead of `Mime::Type[:FOO]` for back compatJeremy Daer2015-10-061-8/+8
| | | | | | | | | | | | | | | | | 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
* Updated Mime Negotiations docs [ci skip]amitkumarsuroliya2015-09-231-4/+4
| | | As we all know that Accessing mime types via constants is deprecated. Now, we are using `Mime::Type[:JSON]` instead of `Mime::JSON`
* don't deal with `nil` valuesAaron Patterson2015-09-221-0/+4
| | | | | We can know whether or not there is a content type object, and just exit early. There is no need to `try` so hard.
* stop calling deprecated methodsAaron Patterson2015-09-211-4/+4
| | | | | We should be asking the mime type method for the mime objects rather than via const lookup
* stop inheriting from Rack::RequestAaron Patterson2015-09-041-3/+3
| | | | | | Just include the modules necessary in the Request object to implement the things we need. This should make it easier to build delegate request objects because the API is smaller
* set cached values in the env hashAaron Patterson2015-08-211-6/+9
|
* stop directly accessing `@env` in mime_negotiationAaron Patterson2015-08-211-8/+8
| | | | | we want to go through methods to access `env` because in the future that ivar may not be available, or may be calculated lazily
* Add ActiveSupport::ArrayInquirer and Array#inquiryGeorge Claghorn2015-03-241-27/+2
| | | | | | | | | | | | | | | | | | | | | | Wrapping an array in an `ArrayInquirer` gives a friendlier way to check its string-like contents. For example, `request.variant` returns an `ArrayInquirer` object. To check a request's variants, you can call: request.variant.phone? request.variant.any?(:phone, :tablet) ...instead of: request.variant.include?(:phone) request.variant.any? { |v| v.in?([:phone, :tablet]) } `Array#inquiry` is a shortcut for wrapping the receiving array in an `ArrayInquirer`: pets = [:cat, :dog] pets.cat? # => true pets.ferret? # => false pets.any?(:cat, :ferret} # => true
* Provide friendlier access to request variantsGeorge Claghorn2015-03-241-7/+34
| | | | Closes #18933.
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-19 09:48:36 +0000