У меня есть веб-сайт на Heroku с собственным доменным именем, зарегистрированным моим клиентом через Network Solutions. Сайт работает по обычным протоколам HTTP и SSL.
Из-за своей распределенной природы Heroku требует, чтобы пользовательские доменные имена указывали на его серверы, используя записи DNS CNAME, нацеленные на www.example.com, а не на вершину A, указывающую на определенный IP-адрес. Из-за этого сайту необходимо перенаправить домен вершины на субдомен www; http://example.com
становится http://www.example.com
. Также, https://example.com
необходимо перенаправить на https://www.example.com
.
Кажется, что все настроено правильно на стороне Heroku в соответствии с их документацией (https://devcenter.heroku.com/articles/ssl-endpoint). На стороне сетевых решений, где настроен DNS, есть запись подстановочного знака CNAME, указывающая все поддомены на адрес конечной точки SSL Heroku:
CNAME * example-1234.herokussl.com
Чтобы перенаправление работало с верхнего домена на субдомен www, я следую указаниям Network Solutions: http://www.networksolutions.com/support/how-to-forward-your-network-solutions-domain-name-to-a-free-blog-service/. Это приводит к следующей записи A:
@ none 205.178.189.129
В результате всего этого http://example.com
правильно перенаправляет на http://www.example.com
. Тем не мение, https://example.com
не только не перенаправляет, но и истекает время ожидания:
% curl -kvI https://example.com
* About to connect() to example.com port 443 (#0)
* Trying 205.178.189.129... Operation timed out
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
Однако подключение через HTTP работает:
% curl -kvI http://example.com
* About to connect() to example.com port 80 (#0)
* Trying 205.178.189.129... connected
* Connected to example.com (205.178.189.129) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.20.0 (i386-apple-darwin8.11.1) libcurl/7.20.0 OpenSSL/0.9.7l zlib/1.2.3 libidn/1.15
> Host: example.com
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
HTTP/1.1 302 Moved Temporarily
< Content-Length: 0
Content-Length: 0
< Location: /?3e3ea140
Location: /?3e3ea140
<
* Connection #0 to host example.com left intact
* Closing connection #0
Таким образом, специальная магия перенаправления Network Solutions, похоже, работает для HTTP, но не для SSL. Кто-нибудь знает, поддерживают ли они такое перенаправление вообще, или мне нужно будет убедить моего клиента перейти к новому регистратору / поставщику DNS?
Согласование HTTP происходит до отправки любого заголовка ответа HTTP (включая код состояния HTTP и заголовок Location).
Это означает, что для перенаправления https
версии, Network Solution должна установить сертификат вашего домена и настроить свой сервер для прослушивания порта 443.
Я не вижу упоминания об этой функции, похоже, что они предоставляют простую службу перенаправления, доступную по этому IP-адресу, но это означает, что вы не можете перенаправить HTTPS-версию своего корневого домена на имя хоста www.
Возможное решение - указать свой корневой домен приложению Heroku (используя одно из имен A, возвращаемых при разрешении конечной точки SSL. Некоторые поставщики DNS также предлагают функцию, подобную CNAME для корневого домена), а затем обрабатывать перенаправление внутренне. Это наиболее распространенный способ перенаправления корневого домена на www для приложения, размещенного на Heroku.