Chrome загружает мой локальный веб-сайт как https вместо http, что приводит к ошибке (началось после обновления ubuntu)
Варианты «без эффектов» и «Gnome Classic» - это те, которые вам понадобятся на настольных компьютерах с небольшим графическим ускорением или без него. Для Compiz и Mutter требуются определенные количества аппаратных средств для запуска.
4 ответа
Если вы перейдете к статье, опубликованной в записи суперпользователя, tl; dr объяснит это:
tl; dr: Chrome 63 (выход с декабря 2017 года) заставит все домены, заканчивающиеся на .dev (и .foo) для перенаправления на HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).Итак, ваши единственные решения - либо изменить что-то, отличное от [F5] TLD, либо создать сертификат и реализовать HTTPS в вашей статье для локальной разработки.
Чтобы объяснить, почему это ваше единственное решение, мне нужно начать с того, что означает HSTS и как оно работает.
HSTS в целом
HSTS - это относительно новый HTTP-заголовок, который при настройке сообщает браузерам, что в следующий раз, когда кто-то перейдет к домену, используйте его только с помощью HTTPS без необходимости перенаправления на стороне сервера.
Для Например, рассмотрим, что вы перешли на http://example.com. В заголовках ответов вы получите следующее:
Strict-Transport-Security: max-age=31536000
Этот заголовок сообщает браузеру, что в течение следующего года (31536000 секунд), когда пользователь обращается к http://example.com, перенаправляет этот URL на https://example.com локально без необходимости перенаправления серверов. И только после этого, зайдите на сайт с помощью https://example.com.
HSTS для поддоменов
Предыдущее действует только для одного домена. Например, если вы попытаетесь получить доступ к http://subdomain.example.com, сайт будет работать без каких-либо переадресаций.
Чтобы решить эту проблему, предыдущий заголовок должен быть изменен на:
Strict-Transport-Security: max-age=31536000; includeSubdomains
Теперь, даже если вы никогда не обращались к каким-либо поддоменам example.com, браузер ВСЕГДА будет перенаправлять субдомены на https перед выполнением запроса.
Предварительная загрузка HSTS
Последний шаг - исправить один последний выпуск. При первом доступе к сайту вы все равно будете обращаться к нему с помощью HTTP, который перенаправит вас на HTTPS и отправит вам заголовок HSTS. Предыдущее не является безопасным и по-прежнему является проблемой безопасности.
Чтобы решить эту проблему, основные браузеры используют список предварительной загрузки HTTP Strict Transport Security (HSTS) для доменов жесткого кода, доступ к которым возможен только с помощью HTTPS. Вы можете найти форму подачи здесь: https://hstspreload.org/
Единственная модификация, которую вам нужно сделать перед отправкой вашего домена, - это изменить заголовок, чтобы он кэшировался в браузерах не менее 2 лет, и добавьте к нему опцию preload.
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
После того, как вы отправите свой домен и как только будет выпущена новая версия Chrome (или любой другой браузер, использующий список предварительной загрузки HSTS Chrome, и не обязательно следующая версия), ваш домен будет жестко закодирован в Chrome как HTTPS-only.
Предварительная загрузка HSTS для TLD
Владельцы TLD разрешены (и поощряются) к https: //hstspreload.org/.
tl; dr: Chrome 63 (с декабря 2017 года) заставит все домены, заканчивающиеся на .dev (и .foo), перенаправляться к HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).
Владельцы gTLD, ccTLD или любых других общедоступных доменов суффикса могут предварительно загружать HSTS во все зарегистрированные регистры. Это обеспечивает надежную защиту для всего TLD и намного проще, чем предварительная загрузка каждого отдельного домена.
И поскольку Google владеет доменом .dev, они сделали именно это. Итак, теперь все *.dev домены будут работать только в HTTPS под Chrome. И поскольку большинство браузеров используют один и тот же список предварительной загрузки, эти браузеры также перестанут работать.
// eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
Если вы не можете изменить текущий домен .dev, вы можете понизить свой Chrome до версии 61 (я сделал это успешно => здесь)
Если вы перейдете к статье, опубликованной в записи суперпользователя, tl; dr объяснит это:
tl; dr: Chrome 63 (выход с декабря 2017 года) заставит все домены, заканчивающиеся на .dev (и .foo) для перенаправления на HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).Итак, ваши единственные решения - либо изменить что-то, отличное от [F5] TLD, либо создать сертификат и реализовать HTTPS в вашей статье для локальной разработки.
Чтобы объяснить, почему это ваше единственное решение, мне нужно начать с того, что означает HSTS и как оно работает.
HSTS в целом
HSTS - это относительно новый HTTP-заголовок, который при настройке сообщает браузерам, что в следующий раз, когда кто-то перейдет к домену, используйте его только с помощью HTTPS без необходимости перенаправления на стороне сервера.
Для Например, рассмотрим, что вы перешли на http://example.com. В заголовках ответов вы получите следующее:
Strict-Transport-Security: max-age=31536000
Этот заголовок сообщает браузеру, что в течение следующего года (31536000 секунд), когда пользователь обращается к http://example.com, перенаправляет этот URL на https://example.com локально без необходимости перенаправления серверов. И только после этого, зайдите на сайт с помощью https://example.com.
HSTS для поддоменов
Предыдущее действует только для одного домена. Например, если вы попытаетесь получить доступ к http://subdomain.example.com, сайт будет работать без каких-либо переадресаций.
Чтобы решить эту проблему, предыдущий заголовок должен быть изменен на:
Strict-Transport-Security: max-age=31536000; includeSubdomains
Теперь, даже если вы никогда не обращались к каким-либо поддоменам example.com, браузер ВСЕГДА будет перенаправлять субдомены на https перед выполнением запроса.
Предварительная загрузка HSTS
Последний шаг - исправить один последний выпуск. При первом доступе к сайту вы все равно будете обращаться к нему с помощью HTTP, который перенаправит вас на HTTPS и отправит вам заголовок HSTS. Предыдущее не является безопасным и по-прежнему является проблемой безопасности.
Чтобы решить эту проблему, основные браузеры используют список предварительной загрузки HTTP Strict Transport Security (HSTS) для доменов жесткого кода, доступ к которым возможен только с помощью HTTPS. Вы можете найти форму подачи здесь: https://hstspreload.org/
Единственная модификация, которую вам нужно сделать перед отправкой вашего домена, - это изменить заголовок, чтобы он кэшировался в браузерах не менее 2 лет, и добавьте к нему опцию preload.
Strict-Transport-Security: max-age=63072000; includeSubdomains; preload
После того, как вы отправите свой домен и как только будет выпущена новая версия Chrome (или любой другой браузер, использующий список предварительной загрузки HSTS Chrome, и не обязательно следующая версия), ваш домен будет жестко закодирован в Chrome как HTTPS-only.
Предварительная загрузка HSTS для TLD
Владельцы TLD разрешены (и поощряются) к https: //hstspreload.org/.
tl; dr: Chrome 63 (с декабря 2017 года) заставит все домены, заканчивающиеся на .dev (и .foo), перенаправляться к HTTPS через предварительно загруженный заголовок HTTP Strict Transport Security (HSTS).
Владельцы gTLD, ccTLD или любых других общедоступных доменов суффикса могут предварительно загружать HSTS во все зарегистрированные регистры. Это обеспечивает надежную защиту для всего TLD и намного проще, чем предварительная загрузка каждого отдельного домена.
И поскольку Google владеет доменом .dev, они сделали именно это. Итак, теперь все *.dev домены будут работать только в HTTPS под Chrome. И поскольку большинство браузеров используют один и тот же список предварительной загрузки, эти браузеры также перестанут работать.
// eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
Если вы не можете изменить текущий домен .dev, вы можете понизить свой Chrome до версии 61 (я сделал это успешно => здесь)