У меня есть давнее приложение Rails, работающее на Mac OS X (apache2). В настройке используются виртуальные хосты Apache и Passenger. Приложение Rails также использует базовую аутентификацию HTTP.
Мне нужно перенести приложение с одного URL-адреса на другой - с некоторым перекрытием обоих доменных имен, доступных одновременно в течение определенного периода.
Для этого я добавил новое доменное имя в качестве ServerAlias существующего доменного имени в конфигурацию виртуального хоста пассажира.
Теперь я могу просматривать приложение Rails, используя как устаревший URL-адрес, так и новый URL-адрес из любого из Safari, Chrome, Firefox или Internet Explorer.
Я также могу отправлять обновления приложения Rails по протоколу HTTP с помощью Safari, Chrome или Firefox. Все хорошо.
Кроме, попытки публиковать обновления из Internet Explorer приводят к тому, что приложение Rails отклоняет обновление,
Журнал приложения Rails содержит сообщение,
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
У меня есть другие домены и псевдонимы, прекрасно работающие на этой же машине.
Приветствуются любые предложения относительно того, что заставляет приложение Rails отклонять сообщения из IE.
ОБНОВЛЕНИЕ: я попытался изменить новый домен на ServerName, а старый домен на ServerAlias, но все же получил 422 с новым доменным именем. Я сбит с толку.
Не знаю, почему это работает, но в надежде, что это поможет кому-то другому ...
Я обнаружил, что сообщения Rails POST от MSIE принимаются, если я настроил новый URL для использования того же поддомена.
Так,
Если он настроен как,
originalsubdomain.originaldomainname.com
Если настроить новый URL как,
newsubdomain.newdomainname.com
... тогда Safari, FireFox и Chrome все счастливы, но MSIE заставляет Rails отказываться от POST (проверено на нескольких машинах).
Однако, если я настрою новый URL-адрес,
originalsubdomain.newdomain.com
Он полностью работает со всеми перечисленными браузерами (проверено на нескольких машинах).
Любые предложения относительно Зачем это могло бы быть оценено.
Внимательно следите за журналами, там у вас должен быть незакодированный символ.
422 означает, что вы получили правильный запрос, но он не может быть обработан из-за (обычно) проблем с кодировкой.
Из рфк
The 422 (Unprocessable Entity) status code means the server
understands the content type of the request entity (hence a
415(Unsupported Media Type) status code is inappropriate), and the
syntax of the request entity is correct (thus a 400 (Bad Request)
status code is inappropriate) but was unable to process the contained
instructions. For example, this error condition may occur if an XML
request body contains well-formed (i.e., syntactically correct), but
semantically erroneous, XML instructions.