Ошибка MIME-типа в InternetExplorer с использованием прокси-сервера

В Internet Explorer запрошенный URL-адрес блокируется из-за несоответствия типа mime. Сценарий заключается в том, что запрос отправляется от клиента на целевой сервер через прокси-сервер. Предположим, что у нас есть A (Клиент), B (Прокси-сервер), C (Целевой сервер). Запрос отправляется от A (клиент) до B (Прокси-сервер) и от B (Прокси-сервер) до C (Целевой сервер). Аналогично, ответ также поступает от C (Destination Server) до B (прокси-сервер) и от B (прокси-сервер) до A (клиента), с которого был инициирован запрос. Теперь проблема заключается в том, что ответ Content-type является "application/liquid", но клиент запускает запрос с помощью "script src= proxyserver/test", поэтому исключенный Content-Type для ответа становится "text/javascript". Невозможно изменить Content-type ответа от "application/liquid" сервера назначения. Весь сценарий отлично работает во всех других браузерах, и ответ легко доступен. Однако в IE, когда мы получаем ошибку как "запрос заблокирован из-за несоответствия типа mime". Так может ли кто-нибудь предоставить решение, как мы можем заставить его работать? Ниже приведен снимок экрана об ошибке.

Ответ 1

Вам нужно создать script, внешний script, который даст вызов требуемому коду с помощью вызова ajax или xmlhttprequest, где вам нужно будет установить заголовок accept таким образом, чтобы нужный тип mime. Таким образом, от клиента он будет вызывать этот внешний script с помощью тега script, который будет выполняться через прокси-сервер и который далее даст вызов фактическим данным и получит его ответ и отправит обратно клиенту. Но поскольку он будет называть script, по умолчанию заголовок будет возвращаться как text/javascript, и ошибка будет решена.

Ответ 2

TL; DR - вам нужно будет изменить типы mime.

Эта проблема возникает, когда ожидаемый тип запросов отличается от типа содержимого ответа (как указано в заголовках). Правильное решение будет заключаться в том, чтобы согласовать заголовки ответов и запросов друг с другом. Это означает, что вызов, который вы делаете "через тег script", должен быть изменен, чтобы иметь тот же заголовок accept в качестве заголовка ответа content-type.

Кроме того, посмотрите документацию:

nosniff Блокирует запрос, если запрошенный тип "стиль" и MIME type не является "text/css" или "script", а тип MIME не является JavaScript MIME.

Смотрите здесь.

Я вижу, что этот URL: https://nirma.myshopify.com/apps/GeoShippingBar/geoShippingBarProxy имеет этот тип содержимого: Content-Type:text/html; charset=utf-8, который не является javascript-mime-type.

Ответ 3

Попробуйте следующее:

response.addHeader( "принимать", "текст/JavaScript" );

устанавливается в ответе тега script, откуда он вызывается.

Ответ 4

В принципе, вы не можете этого сделать. Приложение Proxys предназначено для создания страниц, а не script файлов.

Возможная стратегия, которая поможет вам в том, куда вы хотите пойти, выглядит следующим образом:

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

<script type="text/javascrpt">
   geoShippingConfig = {
       somevalue: '{{ shop.X }}',
       etc
  };
</script>

И вы добавляете это в основной макет, когда ваше приложение установлено. Различные приложения делают такие вещи. Вы должны предупредить клиента, что вы собираетесь на это, но он достаточно мягкий. Вам также нужна кнопка обновления или какой-либо способ повторно ввести фрагмент и включить, когда тема изменится.

Затем ваше приложение устанавливает тэг script с вашим кодом вместо вызова прокси-сервера приложения. Теги script включают магазин в URL-адресе, поэтому вы можете выполнить любую конфигурацию, определенную в приложении, в возвращаемом файле script. Тег script script использует geoShippingConfig при загрузке.