Cache без SSL запрос с Service Worker

Question

Поскольку Service Worker регистрации требуется веб-сайт, чтобы быть подан через HTTPS, Google Chrome выдает ошибку, когда я пытаюсь добавить HTTP ресурс Cache:

Mixed Содержание: постранично " https://example.com/sw.js 'был загружен через HTTPS, но запросил небезопасный ресурс' http://example.com/ '. Этот запрос заблокирован; содержимое должно быть передано через HTTPS.

Я хочу кэшировать основной HTTP-страницу (или, по крайней мере, 301 перенаправление на HTTPS), так как для пользователей, трудно набрать https:// части, особенно на мобильных устройствах, чтобы получить доступ к кэшированной версии моего сайта, когда в автономном режиме.

Возможны ли обходные пути для этого?

Answer 1

Я не думаю, что эту проблему можно решить с помощью сервисного работника, потому что нет способа перехватить запросы к схеме http. Тем не менее, похоже, что Strict-Transport-Security header может работать.

Если это предусмотрено в ответе https, оно заставляет браузер всегда использовать схему https для загрузки страницы - на нее должен попасть сотрудник службы, если он был правильно установлен. Это применяется как в случае, когда пользователь не вводит схему (например, example.com), либо они вводят схему http (например, http://example.com).

Answer 2

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

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API говорит «Работники сферы обслуживания работают только через HTTPS, по соображениям безопасности. Модифицировав сетевые запросы настежь человеку в середине атак было бы очень плохо.

В качестве решения я бы у себя кэш манифест приложения на http с переадресацией на https. Это не будет автоматически кэшироваться, если пользователь сначала зайдет через https, но если это так, пользователь, скорее всего, всегда будет обращаться к странице через https. Если пользователь действительно использует http, он будет кэшировать перенаправление и будет доступно в автономном режиме. Хотя технология устарела, она по-прежнему широко используется, ссылка: https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_application_cache.

Если используется постоянная переадресация 301, маловероятно, что браузер, скорее всего, кэширует перенаправление и загружает https по умолчанию, см.: https://en.wikipedia.org/wiki/HTTP_301.

Надеюсь, это соответствует вашим потребностям, если бы не я хотел бы обсудить проблемы, с которыми вы сталкиваетесь с этим решением.

Answer 3

Если серверные решения, такие как возврат ответа HTTP 301 или включение заголовка Strict-Transport-Security, невозможны из-за вашей настройки обслуживания, то другой вариант - использовать клиентский JavaScript для обновления window.location.href, что приведет к срабатыванию страницы для перезагрузки.

Вы можете следить за техникой, используемую в <platinum-https-redirect> Polymer element, приспособленная под:

function _isLocalhost(hostname) { 
    // !! coerces the logical expression to evaluate to the values true or false. 
    return !!(hostname === 'localhost' || 
      // [::1] is the IPv6 localhost address. 
      hostname === '[::1]' || 
      // 127.0.0.1/8 is considered localhost for IPv4. 
      hostname.match(/^127(?:\.(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}$/)); 
} 

if (window.location.protocol === 'http:' && !_isLocalhost(window.location.hostname)) { 
    // Redirect to https: if we're currently using http: and we're not on localhost. 
    window.location.href = 'https:' + window.location.href.substring(window.location.protocol.length); 
}