Тот же сайт производит "слишком много перенаправлений" только через сотовую связь, а не через WiFi - PullRequest
Новая
       100

Тот же сайт производит "слишком много перенаправлений" только через сотовую связь, а не через WiFi

7 голосов
/ 18 февраля 2020

Я размещаю небольшой веб-сайт у внешнего хост-провайдера. Когда я открываю его из моего iPhone, я получаю разные результаты в зависимости от того, как мой iPhone подключен к inte rnet:

  • Когда соединение установлено через WiFi, моя страница всегда открывается и работает как ожидалось
  • Когда соединение установлено через сотовую связь, моя страница всегда выдает следующее сообщение об ошибке:

На мобильном Safari:

Safari не может откройте страницу, потому что произошло слишком много перенаправлений.

На мобильном телефоне Chrome:

Эта страница не работает / перенаправляет вас слишком много раз.

На мобильном Opera:

Этот сайт не может быть достигнут / слишком много перенаправлений HTTP.

Насколько я могу судить, единственная разница это решает, что будет тип соединения inte rnet - WiFi против сотовой связи. Я не могу найти никаких других отличий.

Поскольку сайт работает нормально через сеть WiFi, я исключил перенаправление l oop на своем сайте (это наиболее часто упоминаемая причина ошибки «слишком много перенаправлений»). , Я также пытался отключить предотвращение межсайтового отслеживания, но результаты остались прежними. Я что-то пропустил? В чем может быть причина этого странного поведения?

Если это уместно, вот несколько вещей о самом веб-сайте:

  • Веб-сайт разработан с ASP . NET Core
  • Я получаю доступ к сайту с использованием https в обоих случаях (через Wi-Fi и через сотовую связь)
  • Сайт находится на поддомене, который использует подстановочный сертификат из «верхнего» домена
  • Сайт использует ASP. NET Базовую аутентификацию "scaffold-ed", которая использует перенаправления и файлы cookie и имеет функцию "запомнить меня".

Ответы [ 5 ]

1 голос
/ 28 февраля 2020

Внедрение https на стороне приложения за обратным прокси довольно сложно. Обычно лучше разрешить обратному прокси-серверу выполнять форсирование и настроить прокси-сервер для связи только по https, чтобы избежать форсирования на стороне приложения. (Если приложение, конечно, имеет возможности https)

Если вы должны сделать это из приложения, то прокси-сервер должен включать необходимые заголовки, чтобы приложение могло оценить исходный контекст соединения. И, возможно, вам придется знать исходное имя хоста и базовый путь, если вы переписываете это.

Пожалуйста, ознакомьтесь с инструкциями для asp. net core Промежуточного промежуточного программного обеспечения ядра Forwarded Headers. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer

Относительно того, почему это ведет себя по-разному, в зависимости от вашего типа соединения inte rnet, остается загадкой.

0 голосов
/ 27 февраля 2020

Я думаю, что ваш поставщик услуг использует apache сервер. если да, пожалуйста, сбросьте файл .htacess (это файл конфигурации сервера, используемый для управления настройками сервера, включая перенаправления).

0 голосов
/ 27 февраля 2020

Это может быть вызвано тем, что браузеры не получают правильный тип контента

Можете ли вы добавить это к вашей голове в представлении или макете (если вы используете) 

<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
</head>
0 голосов
/ 27 февраля 2020

Я наконец наткнулся на исправление, хотя я до сих пор не знаю, почему ошибка не проявляется на настольных компьютерах и мобильных WiFi-соединениях. Эта проблема связана с размещением моего веб-приложения в IIS с использованием внепроцессного режима и вызовом UseHttpsRedirection() во время установки.

Что произойдет дальше, описано в этом ответе : IIS, который подключается к моему внешнему хосту (Kestrel) через http, перенаправляется, и браузер на моем телефоне каким-то образом обнаруживает его. Существует также второе перенаправление (законное) на страницу входа, которое также учитывает браузер телефона. Теперь браузер телефона видит два перенаправления, поэтому он отображает ошибку, потому что разрешено самое большее одно перенаправление.

Исправление было просто для удаления вызова на UseHttpsRedirection(). В сценарии размещения вне процесса это было не нужно: фронт IIS настроен на использование https, поэтому клиенты все равно перенаправляются.

0 голосов
/ 21 февраля 2020

Попробуйте добавить строку ниже в ваш файл Web.Config. Похоже, это может быть связано с тем, как мобильные сети пытаются сжимать ваши пакеты при их отправке обратно на устройство. 

<system.webServer>
   <httpProtocol>
     <customHeaders>
     <add name="Cache-Control" value="no-transform" />
     </customHeaders>
   </httpProtocol>
</system.webServer>

, что, я считаю, эквивалентно добавлению Header set Cache-Control "no-transform" к вашему .htaccess файл.

Если это не сработает, попробуйте добавить следующее на все страницы, к которым обычно нужно обращаться при запросе. 

<% @Language="VBScript" %>
<% Response.CacheControl = "no-transform" %>

ПРИМЕЧАНИЕ. Этот код необходимо вставить в начале страницы, если не включена буферизация, поскольку она изменяет заголовки HTTP.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Похожие темы

...