Description
Rack middleware that lets you define a single host name as the canonical host for your application. Requests for other host names will then be redirected to the canonical host.
Rack Canonical Host alternatives and similar gems
Based on the "SEO" category.
Alternatively, view Rack Canonical Host alternatives based on common mentions on social networks and blogs.
-
FriendlyId
FriendlyId is the “Swiss Army bulldozer” of slugging and permalink plugins for ActiveRecord. It allows you to create pretty URL’s and work with human-friendly strings as if they were numeric ids for ActiveRecord models. -
SitemapGenerator
SitemapGenerator is a framework-agnostic XML Sitemap generator written in Ruby with automatic Rails integration. It supports Video, News, Image, Mobile, PageMap and Alternate Links sitemap extensions and includes Rake tasks for managing your sitemaps, as well as many other great features.
Scout Monitoring - Performance metrics and, now, Logs Management Monitoring with Scout Monitoring
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of Rack Canonical Host or a related project?
README
Rack Canonical Host
Rack middleware that lets you define a single host name as the canonical host for your application. Requests for other host names will then be redirected to the canonical host.
Installation
Add this line to your application’s Gemfile
:
gem 'rack-canonical-host'
And then execute:
$ bundle
Or install it yourself as:
$ gem install rack-canonical-host
Usage
For most applications, you can insert the middleware into the config.ru
file
in the root of the application.
Here’s a simple example of what the config.ru
in a Rails application might
look like after adding the Rack::CanonicalHost
middleware.
require 'rack/canonical_host'
require ::File.expand_path('../config/environment', __FILE__)
use Rack::CanonicalHost, 'example.com'
run YourRailsApp::Application
In this case, any requests coming in that aren't for the specified host,
example.com
, will be redirected, keeping the requested path intact.
Environment-Specific Configuration
You probably don't want your redirect to happen when developing locally. One way to prevent this from happening is to use environment variables in your production environment to set the canonical host name.
With Heroku, you would do this like so:
$ heroku config:add CANONICAL_HOST=example.com
Then, can configure the middleware like this:
use Rack::CanonicalHost, ENV['CANONICAL_HOST'] if ENV['CANONICAL_HOST']
Now, the middleware will only be used if a canonical host has been defined.
Options
If you’d like the middleware to ignore certain hosts, use the :ignore
option, which accepts a string, a regular expression, or an array of either.
use Rack::CanonicalHost, 'example.com', ignore: 'api.example.com'
In this case, requests for the host api.example.com
will not be redirected.
Alternatively, you can pass a block whose return value will be used as the canonical host name.
use Rack::CanonicalHost do |env|
case env['RACK_ENV'].to_sym
when :staging then 'staging.example.com'
when :production then 'example.com'
end
end
If you want it to react only on specific hosts within a multi-domain
environment, use the :if
option, which accepts a string, a regular
expression, or an array of either.
use Rack::CanonicalHost, 'example.com', if: /.*\.example\.com/
use Rack::CanonicalHost, 'example.ru', if: /.*\.example\.ru/
Cache-Control
To avoid browsers indefinitely caching a 301
redirect, it’s a sensible idea
to set an expiry on each redirect, to hedge against the chance you may need to
change that redirect in the future.
# Leave caching up to the browser (which could cache it indefinitely):
use Rack::CanonicalHost, 'example.com'
# Cache the redirect for up to an hour:
use Rack::CanonicalHost, 'example.com', cache_control: 'max-age=3600'
# Prevent caching of redirects:
use Rack::CanonicalHost, 'example.com', cache_control: 'no-cache'
Contributing
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature.'
) - Push to the branch (
git push origin my-new-feature
) - Create a new Pull Request
Contributors
Thanks to the following people who have contributed patches or helpful suggestions:
- Pete Nicholls
- Tyler Ewing
- Thomas Maurer
- Jeff Carbonella
- Joost Schuur
- Jon Wood
- Peter Baker
- Nathaniel Bibler
- Eric Allam
- Fabrizio Regini
- Daniel Searles
Copyright
Copyright © 2009-2017 Tyler Hunt.
Released under the terms of the MIT license. See LICENSE for details.
*Note that all licence references and agreements mentioned in the Rack Canonical Host README section above
are relevant to that project's source code only.