1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/actionpack/lib/action_controller/metal/url_for.rb

51 lines
1.7 KiB
Ruby
Raw Normal View History

module ActionController
# Includes +url_for+ into the host class. The class has to provide a +RouteSet+ by implementing
# the <tt>_routes</tt> method. Otherwise, an exception will be raised.
#
# In addition to <tt>AbstractController::UrlFor</tt>, this module accesses the HTTP layer to define
# url options like the +host+. In order to do so, this module requires the host class
# to implement +env+ and +request+, which need to be a Rack-compatible.
#
# class RootUrl
# include ActionController::UrlFor
# include Rails.application.routes.url_helpers
#
2012-10-27 16:05:27 -04:00
# delegate :env, :request, to: :controller
#
# def initialize(controller)
# @controller = controller
# @url = root_path # named route from the application.
# end
# end
module UrlFor
extend ActiveSupport::Concern
include AbstractController::UrlFor
def url_options
2014-05-21 18:51:28 -04:00
@_url_options ||= {
:host => request.host,
:port => request.optional_port,
:protocol => request.protocol,
2012-08-04 07:55:00 -04:00
:_recall => request.symbolized_path_parameters
2014-05-21 18:51:28 -04:00
}.merge(super).freeze
2010-09-27 15:14:18 -04:00
2014-04-30 17:24:14 -04:00
if (same_origin = _routes.equal?(env["action_dispatch.routes".freeze])) ||
Fix handling SCRIPT_NAME from within mounted engine's When you mount your application at a path, for example /myapp, server should set SCRIPT_NAME to /myapp. With such information, rails application knows that it's mounted at /myapp path and it should generate routes relative to that path. Before this patch, rails handled SCRIPT_NAME correctly only for regular apps, but it failed to do it for mounted engines. The solution was to hardcode default_url_options[:script_name], which is not the best answer - it will work only when application is mounted at a fixed path. This patch fixes the situation by respecting original value of SCRIPT_NAME when generating application's routes from engine and the other way round - when you generate engine's routes from application. This is done by using one of 2 pieces of information in env - current SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because we have 2 cases to handle: - generating engine's route from application: in this situation SCRIPT_NAME is basically SCRIPT_NAME set by the server and it indicates the place where application is mounted, so we can just pass it as :original_script_name in url_options. :original_script_name is used because if we use :script_name, router will ignore generating prefix for engine - generating application's route from engine: in this situation we already lost information about the SCRIPT_NAME that server used. For example if application is mounted at /myapp and engine is mounted at /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that we need to keep reference to /myapp SCRIPT_NAME by binding it to the current router. Later on we can extract it and use when generating url Please note that starting from now you *should not* use default_url_options[:script_name] explicitly if your server already passes correct SCRIPT_NAME to rack env. (closes #6933)
2012-08-10 17:27:51 -04:00
(script_name = env["ROUTES_#{_routes.object_id}_SCRIPT_NAME"]) ||
(original_script_name = env['ORIGINAL_SCRIPT_NAME'.freeze])
@_url_options.dup.tap do |options|
Fix handling SCRIPT_NAME from within mounted engine's When you mount your application at a path, for example /myapp, server should set SCRIPT_NAME to /myapp. With such information, rails application knows that it's mounted at /myapp path and it should generate routes relative to that path. Before this patch, rails handled SCRIPT_NAME correctly only for regular apps, but it failed to do it for mounted engines. The solution was to hardcode default_url_options[:script_name], which is not the best answer - it will work only when application is mounted at a fixed path. This patch fixes the situation by respecting original value of SCRIPT_NAME when generating application's routes from engine and the other way round - when you generate engine's routes from application. This is done by using one of 2 pieces of information in env - current SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because we have 2 cases to handle: - generating engine's route from application: in this situation SCRIPT_NAME is basically SCRIPT_NAME set by the server and it indicates the place where application is mounted, so we can just pass it as :original_script_name in url_options. :original_script_name is used because if we use :script_name, router will ignore generating prefix for engine - generating application's route from engine: in this situation we already lost information about the SCRIPT_NAME that server used. For example if application is mounted at /myapp and engine is mounted at /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that we need to keep reference to /myapp SCRIPT_NAME by binding it to the current router. Later on we can extract it and use when generating url Please note that starting from now you *should not* use default_url_options[:script_name] explicitly if your server already passes correct SCRIPT_NAME to rack env. (closes #6933)
2012-08-10 17:27:51 -04:00
if original_script_name
options[:original_script_name] = original_script_name
else
options[:script_name] = same_origin ? request.script_name.dup : script_name
end
options.freeze
end
else
@_url_options
end
end
end
end