Автообнаружение 404
После долгих исследований и испытаний я применил правила перенаправления для проверки автообнаружения где-то еще, кроме моего веб-сервера. В этом посте я пытаюсь выяснить, что может быть не так (может быть, ничего плохого, я просто хочу проверить проверку) о том, почему перенаправления, которые у меня есть, не работают на моем виртуальном хосте на моем веб-сервере Apache. Я включил три перенаправления, которые я сохранил в виртуальном хосте 443:
Redirect permanent /autodiscover/autodiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
Redirect permanent /AutoDiscover/AutoDiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
Redirect permanent /Autodiscover/Autodiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
После перезапуска Apache я запустил инструмент https://testconnectivity.microsoft.com/, чтобы убедиться, что перенаправления работают, и я все еще вижу следующее в моих журналах ошибок.
192.168.9.16 - - [15/Aug/2018:16:05:12 -0700] "POST /Autodiscover/Autodiscover.xml HTTP/1.1" 404 38531 "-" "Microsoft Office/15.0 (Windows NT 6.2; Microsoft Outlook 15.0.4615; Pro; MS Connectivity Analyzer)"
192.168.9.16 - - [15/Aug/2018:16:05:13 -0700] "POST /Autodiscover/Autodiscover.xml HTTP/1.1" 404 38556 "-" "Microsoft Office/15.0 (Windows NT 6.2; Microsoft Outlook 15.0.4615; Pro; MS Connectivity Analyzer)"
Теперь это чисто косметический характер для решения этой проблемы - все мои пользователи могут отправлять и получать электронные письма без проблем, это то, что мы в ИТ-команде хотели бы исправить. Мои журналы ошибок не полны ошибок 404, перечисленные выше ошибки отображаются только при запуске инструмента - не в том случае, если / когда пользователь настраивает свои почтовые клиенты (на компьютере или телефоне); Я проверил это и посмотрел журналы, чтобы увидеть, не появилось ли в журналах что-либо, связанное с результатами анализатора соединений... ничего.
Я обратился к самим Microsoft, предоставив им результаты инструмента анализа подключений и ответ: "Ваша учетная запись настроена правильно, и нет необходимости в дальнейшем тестировании, и это ожидаемый результат". Я не затаил дыхание, чтобы получить реальный ответ от них, но я думал, что по крайней мере попробую. Как я уже упоминал, это то, что мы в ИТ хотели бы решить, но это никак не повлияет на моих пользователей.
Кто-нибудь еще, у которого веб-сервер их компании размещен внутри и использует Office365, сталкивался с этой проблемой в прошлом? Если так, что ты сделал, чтобы исправить это - если ты сделал что-нибудь? Любой гуру Linux/Apache там видит что-то, что я не ловлю?
Я более чем готов предоставить любую дополнительную информацию, которая может вам понадобиться для оказания помощи; как всегда, если это не соответствует правилам форматирования или требуется дополнительная информация, пожалуйста, дайте мне знать, и я внесу изменения или предоставлю дополнительную информацию. Большое спасибо!
1 ответ
Ваша учетная запись настроена правильно, и дальнейшая проверка не требуется, и это ожидаемый результат.
Это фактический ответ: нет проблем с не перенаправлением /Autodiscover/Autodiscover.xml
, Несмотря на использование протокола HTTPS, Outlook не является веб-браузером, и его не следует рассматривать как один. Outlook не заботится о ваших перенаправлениях. Вместо этого, учитывая 404
(или любой другой, кроме 200
) ответ переходит к следующему кандидату, как описано в Обзоре процесса автообнаружения и службе автообнаружения.
Итак, эффективно ваш autodiscover.plymouthinc.com. IN CNAME autodiscover.outlook.com.
делает трюк. Как указано в вашем вопросе, клиенты даже не используют plymouthinc.com
для автоматического обнаружения, и если они сделали, это не считается ошибкой. Вот почему это действительно ожидаемый результат. Перестань беспокоиться.
Еще одно заблуждение, не связанное с автообнаружением: если вам действительно нужно перенаправить POST
запросы, имейте в виду, что Redirect permanent
возвращает код состояния 301
Перемещено навсегда, в результате чего URL из Location:
заголовок, полученный с помощью GET
метод. Если вам нужно сохранить данные POST, используйте код состояния 307
Временный редирект, вместо этого. (См. RFC 7231 6.4.2. И 6.4.7.)