Используют ли браузеры заголовки подсказок ресурсов (Link) в ответах на перенаправление?

Question

проблема

У меня есть сайт, который использует редирект 302 для новых посетителей, чтобы установить новый сеанс. Я создал демо основного потока на моем личном сайте:

1. https://crenshaw.dev/redirect/index.php (302)
2. https://crenshaw.dev/session/redirect/index.html (200)

index.html использует ресурс https://mac9416.com/demos/style.css (мне просто нужно внешнее доменное имя).

Я хочу указать браузеру подключиться к mac9416.com в 302, а не в 200.

Потенциальное решение

Некоторые браузеры поддерживают заголовки подсказок ресурсов. Вот несколько примеров:

ПРИМЕР 5

Ссылка: https://widget.com; rel = dns-prefetch
Ссылка: https://example.com; rel = preconnect
Ссылка: https://example.com/next-page.html; rel = prerender;
Ссылка: https://example.com/logo-hires.jpg; rel = prefetch; а = изображения; * +1038 *

Что пошло не так

Инструменты разработчика показывают заголовок Link в первоначальном запросе:

Я вижу соединение с mac9416.com, установленное после 200, непосредственно перед загрузкой ресурса.

Я ожидал увидеть соединение, установленное сразу после 302 или просто отсутствующее на временной шкале.

Я тестировал с использованием Chrome 73. Водопад WebPageTest выглядит практически идентично.

Примечание: Мне интересны серверные решения, но сейчас рассматриваемый сайт работает с HTTP1.1.

Вопрос

Я пытаюсь что-то, что даже не поддерживается? Должны ли заголовки подсказок к ресурсам обслуживаться только для ответов без перенаправления?

Раздел «Анонимное перенаправление» рабочего проекта подсказки ресурса наводит меня на мысль, что это должно помочь именно в моем типе ситуации. Но, возможно, я неправильно читаю.

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

Answer 1

Ну, я проверил ваш эксперимент (спасибо, что подобрал его!) И не увидел в этом ничего плохогоЯ также повторил это на своем собственном сервере и могу подтвердить ваши выводы: ни один из основных браузеров, похоже, не поддерживает подсказки ресурсов при перенаправлении страниц.

Что касается абзаца из проекта спецификации, на который вы указываете, я могу подуматьиз двух объяснений:

1. Это является потенциальным вариантом использования, и браузеры просто не поддерживают его (пока).
2. Эта формулировка больше предназначена для ресурсовна текущей странице, которые должны пройти через редирект в первую очередь.Так, если, например, текущая страница (index.html) загружает www.example.com/latest/framework.js, и это перенаправляет на cdn.example.com/latest/framework.js, чтобы фактически загрузить этот ресурс.Примечательно, что только prefetch и prerender явно отмечают, что они предназначены для «следующей навигации» (хотя я попробовал эти два из интереса, и они также не работают для сценария перенаправления).

Либокак я согласен, это может быть яснее.Я собирался предложить открыть вопрос о Github, но посмотрите, вы уже сделали это !Надеемся, что авторы спецификации могут подтвердить это.

Между прочим, я попытался с редиректом JavaScript вместо 301/302, и он работал в Chrome как для заголовка HTTP-ссылки, так и для инструкции HTML-ссылки для предварительного соединения - снова предлагая 200 ответовищутся для подсказок ресурса.

Интересный вопрос, который вы подняли!Не уверен, что не по теме для StackOverflow, но, конечно, пробудил мой интерес ...