Вопросы Теги

Я получаю эту ошибку квоты для 'logging.googleapis.com/read_requests'

У меня было настроено правило перезаписи URL в корне IIS ( ApplicationHost.config ), которое перенаправляет www.example. com на HTTPS. Конфигурация перезаписи URL настраивается на экземпляре IIS за общедоступным балансировщиком нагрузки нашего хостинга, где наш SSL установлен нашим хостинг-провайдером. Балансировщик нагрузки предоставляет нам заголовок X-Forwarded-Proto , который устанавливает значение http , если исходный запрос находится в HTTP, и https , если исходный запрос находится в HTTPS. .

Перезапись URL настраивается следующим образом: 

 Pattern: .*
 Conditions: Match All
             Input                   |Type                |Pattern
             -------------------------------------------------------------
             {HTTP_HOST}             |Matches the Pattern |www.example.com
             {HTTP_X_Forwarded_Proto}|Matches the Pattern |^http$
 Action:
  Redirect to URL: https://{HTTP_HOST}{REQUEST_PATH}
  Redirect Type  : 302

Проблема в том, что у нас был сценарий PowerShell, установленный на самом веб-сервере, чтобы проверить, доступен ли веб-сайт или нет, используя [System.Net.WebRequest ] :: Создать ($ siteUrl) . Сценарий чаще всего сообщает HTTP 200 (OK), но иногда дает сбой 404 HTTP Error. Поскольку сценарий PowerShell выполняется локально, он не должен иметь заголовок X-Forwarded-Proto и никогда не получать 404 от IIS.

Возможно ли каким-либо образом, что перезапись URL-адреса запускается, когда он не должен ?

0
задан 31 October 2017 в 03:11
1 ответ

Я рекомендую включить отслеживание неудачных запросов поскольку это мощный инструмент, позволяющий увидеть, как модули, включая модуль URL Rewrite, обрабатывают запрос. Без него это мое предположение на данный момент.

Вот мое предположение : это зависит от файлов хостов и / или DNS-сервера, настроенного на самом сервере IIS. Однако даже при локальном запуске www.example.com может возвращаться к IP-адресу балансировщика нагрузки, и запрос может возвращаться через балансировщик нагрузки и, следовательно, иметь заголовок X-Forwarded-Proto. Мы сможем увидеть, присутствует ли заголовок при отслеживании неудачных запросов.

Примечание (в основном из моего OCD): я бы рекомендовал изменить шаблон с www.example.com на www (обратная косая черта) .example (обратная косая черта) .com, чтобы указать при перезаписи URL, что точка (.) является буквальной точкой, а не точкой дикого символа. Замените (обратную косую черту) фактическим символом. Похоже, ТАК убирает для меня характер.

0
ответ дан 5 December 2019 в 07:11

Теги

Похожие вопросы