stringtranslate.com

перенаправление URL-адресов

Перенаправление URL-адресов , также называемое перенаправлением URL-адресов , представляет собой метод Всемирной паутины , позволяющий сделать веб-страницу доступной по нескольким URL- адресам. Когда веб-браузер пытается открыть URL-адрес, который был перенаправлен, открывается страница с другим URL-адресом. Аналогичным образом, перенаправление домена или перенаправление домена — это когда все страницы в домене URL перенаправляются в другой домен, например, когда wikipedia.com и wikipedia.net автоматически перенаправляются на wikipedia.org.

Перенаправление URL-адресов выполняется по разным причинам:

Цели

Есть несколько причин использовать перенаправление URL-адресов:

Принудительное использование HTTPS

Веб-сайт потенциально может быть доступен как по безопасной схеме URI HTTPS , так и по обычному HTTP (небезопасный URI, начинающийся с «http://»).

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

В противном случае связь с веб-сайтом будет осуществляться через HTTP. Оператор веб-сайта может решить обслуживать такие запросы, перенаправляя браузер на вариант HTTPS и, надеюсь, также настраивая HSTS для будущих доступов.

Похожие доменные имена

Пользователь может ошибиться в вводе URL-адреса. Организации часто регистрируют эти домены с ошибками и перенаправляют их в нужное место. Этот метод часто используется для «резервирования» других доменов верхнего уровня (TLD) с тем же именем или для облегчения сайта «.edu» или «.net» размещения пользователей, вводящих «.com».

Перенос страниц на новый домен

Веб-страницы могут быть перенаправлены на новый домен по трем причинам:

Благодаря перенаправлению URL-адресов входящие ссылки на устаревший URL-адрес могут быть отправлены в правильное место. Эти ссылки могут быть с других сайтов, которые еще не осознали, что произошли изменения, или из закладок/избранного, которые пользователи сохранили в своих браузерах. То же самое относится и к поисковым системам . Они часто содержат в своей базе данных старые/устаревшие доменные имена и ссылки и отправляют поисковых пользователей на эти старые URL-адреса. Используя перенаправление «перемещено навсегда» на новый URL-адрес, посетители все равно будут попадать на правильную страницу. Кроме того, на следующем проходе поисковая система должна обнаружить и использовать новый URL-адрес.

Логирование исходящих ссылок

Журналы доступа большинства веб-серверов хранят подробную информацию о том, откуда пришли посетители и как они просматривали размещенный сайт. Однако они не регистрируют ссылки на оставленных посетителей. Это связано с тем, что браузеру посетителя нет необходимости взаимодействовать с исходным сервером, когда посетитель нажимает на исходящую ссылку. Эту информацию можно получить несколькими способами. Один из способов включает перенаправление URL-адресов. Вместо того, чтобы отправлять посетителя прямо на другой сайт, ссылки на сайте могут вести на URL-адрес в домене исходного веб-сайта, который автоматически перенаправляет на реальную цель. Недостатком этого метода является задержка, вызванная дополнительным запросом к серверу исходного веб-сайта. Поскольку этот добавленный запрос оставит след в журнале сервера, показывающий, по какой именно ссылке был выполнен переход, это также может быть проблемой конфиденциальности. [1] Тот же метод также используется некоторыми корпоративными веб-сайтами для реализации заявления о том, что последующий контент находится на другом сайте и, следовательно, не обязательно связан с корпорацией. В таких сценариях отображение предупреждения вызывает дополнительную задержку.

Короткие псевдонимы для длинных URL-адресов

Веб-приложения часто включают в свои URL-адреса длинные описательные атрибуты, которые представляют иерархии данных, структуры команд, пути транзакций и информацию о сеансе. В результате такой практики получается URL-адрес, который эстетически неприятен и труден для запоминания и может не соответствовать ограничениям размера сайтов микроблогов . Службы сокращения URL-адресов решают эту проблему, перенаправляя пользователя на более длинный URL-адрес с более короткого. [1]

Значимые, постоянные псевдонимы для длинных или меняющихся URL-адресов.

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

Опубликовать/Перенаправить/Получить

Post/Redirect/Get (PRG) — это шаблон веб-разработки , который предотвращает дублирование отправки форм , если пользователь нажимает кнопку обновления после отправки формы, создавая более интуитивно понятный интерфейс для пользовательских агентов (пользователей).

Таргетинг на устройства и геотаргетинг

Перенаправления можно эффективно использовать для целей таргетинга, таких как геотаргетинг . Таргетинг на устройства становится все более важным с появлением мобильных клиентов. Существует два подхода к обслуживанию мобильных пользователей: сделать веб-сайт адаптивным или перенаправить на мобильную версию веб-сайта. Если предлагается мобильная версия веб-сайта, пользователи мобильных клиентов будут автоматически перенаправлены на соответствующий мобильный контент. Для таргетинга на устройства используются перенаправления на стороне клиента или некэшируемые перенаправления на стороне сервера. Геотаргетинг — это подход, позволяющий предлагать локализованный контент и автоматически перенаправлять пользователя на локализованную версию запрошенного URL-адреса. Это полезно для веб-сайтов, ориентированных на аудиторию более чем в одном месте и/или на разных языках. Обычно для геотаргетинга используются перенаправления на стороне сервера, но в зависимости от требований можно использовать и перенаправления на стороне клиента. [2]

Манипулирование поисковыми системами

Перенаправления использовались для манипулирования поисковыми системами с неэтичными намерениями, например, для перехвата URL-адресов . Целью вводящих в заблуждение перенаправлений является перенаправление поискового трафика на целевые страницы, которые сами по себе не обладают достаточной рейтинговой силой или которые лишь отдаленно или вообще не связаны с целью поиска. Этот подход требует ранжирования по ряду поисковых запросов с рядом URL-адресов, которые будут использовать скрытые перенаправления для перенаправления пользователя на целевую страницу. Этот метод возродился с появлением мобильных устройств и таргетинга на устройства. Перехват URL-адреса — это метод перенаправления за пределы домена [3] , в котором используется характер обработки поисковой системой временных перенаправлений. Если встречается временное перенаправление, поисковые системы должны решить, присваивают ли они значение ранжирования URL-адресу, который инициализирует перенаправление, или целевому URL-адресу перенаправления. URL-адрес, инициирующий перенаправление, может оставаться в результатах поиска, поскольку перенаправление указывает на временный характер. При определенных обстоятельствах можно было использовать это поведение, применяя временные перенаправления к URL-адресам с высоким рейтингом, что приводило к замене исходного URL-адреса в результатах поиска URL-адресом, который инициировал перенаправление, тем самым «крадя» рейтинг. Этот метод обычно сочетался со скрытыми перенаправлениями, чтобы перенаправить поток пользователей с результатов поиска на целевую страницу. Поисковые системы разработали эффективные технологии для обнаружения такого рода манипулятивных подходов. Крупные поисковые системы обычно применяют жесткие штрафы к ранжированию сайтов, уличенных в применении подобных методов. [4]

Манипулирование посетителями

Перенаправление URL-адресов иногда используется как часть фишинговых атак, которые сбивают посетителей с толку относительно того, какой веб-сайт они посещают. [5] Поскольку современные браузеры всегда показывают реальный URL-адрес в адресной строке, угроза снижается. Однако перенаправления также могут привести вас на сайты, которые в противном случае попытаются атаковать другими способами. Например, перенаправление может привести пользователя на сайт, который попытается обманом заставить его загрузить антивирусное программное обеспечение и вместо этого установить какой-либо троян .

Удаление referrerинформации

При нажатии на ссылку браузер отправляет в HTTP-запросе поле Referer , которое указывает источник ссылки. Это поле заполняется URL-адресом текущей веб-страницы и попадает в журналы сервера, обслуживающего внешнюю ссылку. Поскольку конфиденциальные страницы могут иметь конфиденциальные URL-адреса (например, https://company.com/plans-for-the-next-release-of-our-product), нежелательно, чтобы referrerURL-адрес покидал организацию. Страница перенаправления, которая скрывает реферер, может быть встроена во все внешние URL-адреса, преобразуясь, например, https://externalsite.com/pageв формат https://redirect.company.com/https://externalsite.com/page. Этот метод также исключает другую потенциально конфиденциальную информацию из URL-адреса реферера, такую ​​​​как идентификатор сеанса , и может снизить вероятность фишинга , указывая конечному пользователю, что он передал чистый шлюз на другой сайт.

Выполнение

Несколько различных типов ответа браузеру приведут к перенаправлению. Они различаются в зависимости от того, влияют ли они на заголовки HTTP или на содержимое HTML. Используемые методы обычно зависят от роли человека, реализующего их, и его доступа к различным частям системы. Например, веб-автор, не контролирующий заголовки, может использовать метатег «Обновить», тогда как администратор веб-сервера, перенаправляющий все страницы сайта, с большей вероятностью будет использовать конфигурацию сервера.

Ручное перенаправление

Самый простой способ — попросить посетителя перейти по ссылке на новую страницу, обычно используя привязку HTML, например:

Перейдите по <a href = "https://www.example.com/" > этой ссылке < / a > . _  _

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

Коды состояния HTTP 3xx

В протоколе HTTP , используемом во Всемирной паутине , перенаправление — это ответ с кодом состояния, начинающимся с 3 , который заставляет браузер отображать другую страницу. Если клиент сталкивается с перенаправлением, ему необходимо принять ряд решений, как обрабатывать перенаправление. Клиенты используют разные коды состояния, чтобы понять цель перенаправления, как обрабатывать кэширование и какой метод запроса использовать для последующего запроса.

HTTP/1.1 определяет несколько кодов состояния для перенаправления (RFC 7231):

Коды состояния 304 не изменено и 305 использовать прокси не являются перенаправлениями.

Все эти коды состояния требуют, чтобы URL-адрес цели перенаправления был указан в заголовке Location: ответа HTTP. В списке из 300 вариантов выбора обычно все варианты перечислены в теле сообщения, а выбор по умолчанию отображается в заголовке Location:.

Пример HTTP-ответа на перенаправление 301

HTTP - ответ с перенаправлением 301 «перемещено навсегда» выглядит следующим образом:

HTTP / 1.1  301  Перемещено навсегда Местоположение :  https://www.example.org/ Тип контента :  text/html Длина контента :  174< html > < head > < title > Перемещено </ title > </ head > < body >=Перемещено=< p > Эта страница переехала на <a href = "https://www.example.org/" > https://www.example.org/ < / a > . _ </ p > </ body > </ html >

Использование серверных сценариев для перенаправления

Веб-авторы, создающие HTML-контент, обычно не могут создавать перенаправления с использованием заголовков HTTP, поскольку они генерируются автоматически программой веб-сервера при обслуживании HTML-файла. То же самое обычно справедливо даже для программистов, пишущих сценарии CGI, хотя некоторые серверы позволяют сценариям добавлять собственные заголовки (например, путем включения «неразбираемых заголовков»). Многие веб-серверы генерируют код состояния 3xx, если сценарий выводит строку заголовка «Location:». Например, в PHP можно использовать функцию «заголовок»:

заголовок ( 'HTTP/1.1 301 перемещен навсегда' ); заголовок ( 'Местоположение: https://www.example.com/' ); Выход ();

Для предотвращения кэширования могут потребоваться дополнительные заголовки. [7] Программист должен убедиться, что заголовки выводятся раньше тела. Это может нелегко сочетаться с естественным потоком управления через код. Чтобы помочь в этом, некоторые платформы для создания контента на стороне сервера могут буферизовать данные тела. В языке сценариев ASP это также можно выполнить с помощью response.buffer=trueHTTP response.redirect "https://www.example.com/"/1.1, допускающего либо относительную ссылку URI, либо абсолютную ссылку URI. [8] Если ссылка URI является относительной, клиент вычисляет требуемую абсолютную ссылку URI в соответствии с правилами, определенными в RFC 3986. [9]

HTTP-сервер Apache mod_rewrite

Расширение mod_alias Apache HTTP Server можно использовать для перенаправления определенных запросов. Типичные директивы конфигурации выглядят так:

 Постоянное перенаправление /oldpage.html https://www.example.com/newpage.html Перенаправление 301 /oldpage.html https://www.example.com/newpage.html

Для более гибкого перезаписи и перенаправления URL-адресов можно использовать Apache mod_rewrite. Например, чтобы перенаправить запросы на каноническое доменное имя:

RewriteEngine on RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC] RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L]

Такую конфигурацию можно применить к одному или всем сайтам на сервере через файлы конфигурации сервера или к одному каталогу контента через файл .htaccess.

переписать nginx

Nginx имеет встроенный модуль перезаписи http [10] , который можно использовать для расширенной обработки URL-адресов и даже создания веб-страниц (с помощью returnдирективы). Показательным примером такого расширенного использования модуля перезаписи является mdoc.su. Архивировано 3 апреля 2022 года на Wayback Machine , который реализует детерминированный сервис сокращения URL-адресов полностью с помощью только языка конфигурации nginx. [11] [12]

Например, если /DragonFlyBSD/HAMMER.5бы пришел запрос на, он сначала был бы перенаправлен внутри /d/HAMMER.5с помощью первой директивы перезаписи ниже (влияющей только на внутреннее состояние, без каких-либо HTTP-ответов, выданных клиенту), а затем со второй директивой перезаписи. директиве HTTP-ответ с кодом состояния 302 Found будет выдан клиенту для фактического перенаправления на внешний cgi - скрипт webman : [13]

 location /DragonFly { переписать ^/DragonFly(BSD)?([,/].*)? $ /d $2 последний ; } location /d { set $db "https://leaf.dragonflybsd.org/cgi/web-man?command=" ; установите $ds "§ion=" ; перезаписать ^/./([^/]+)\.([1-9]) $ $db$1$ds$2 перенаправление ; }

Обновить метатег и заголовок обновления HTTP.

Netscape представил функцию метаобновления , которая обновляет страницу через определенное время. Это может указать новый URL-адрес для замены одной страницы другой. Это поддерживается большинством веб-браузеров. [14] [15] Тайм-аут в ноль секунд приводит к немедленному перенаправлению. Google рассматривает это как постоянное перенаправление 301, позволяя передавать PageRank на целевую страницу. [16]

Это пример простого HTML-документа, в котором используется этот метод:

< html > < head >  < meta  http-equiv = "Обновить"  content = "0; url=https://www.example.com/"  /> </ head > < body >  < p > Пожалуйста, следуйте < a  href = "https://www.example.com/" > эта ссылка </ a > . </ p > </ body > </ html >

Этот метод могут использовать веб-авторы , поскольку метатег содержится внутри самого документа. Метатег должен быть размещен в разделе «head» HTML-файла. Число «0» в этом примере можно заменить другим числом, чтобы добиться задержки на такое же количество секунд. Якорь в разделе «body» предназначен для пользователей, браузеры которых не поддерживают эту функцию.

Того же эффекта можно добиться с помощью HTTP- refreshзаголовка:

HTTP / 1.1  200  ОК Обновить :  0; url=https://www.example.com/ Тип контента :  text/html Длина контента :  78Перейдите по <a href = "https://www.example.com/" > этой ссылке < / a > . _  _

Этот ответ легче сгенерировать с помощью программ CGI, поскольку не нужно менять код состояния по умолчанию.

Вот простая программа CGI, которая осуществляет это перенаправление:

# !/usr/bin/perl print "Обновить: 0; url=https://www.example.com/\r\n" ; напечатать «Тип контента: text/html\r\n» ; напечатайте "\r\n" ; print "Перейдите по <a href=\"https://www.example.com/\">этой ссылке</a>!"

Примечание. Обычно HTTP-сервер автоматически добавляет строку состояния и заголовок Content-Length.

W3C не рекомендует использовать метаобновление, поскольку оно не передает браузеру (или поисковой системе ) никакой информации ни об исходном, ни о новом ресурсе . Рекомендации W3C по доступности веб-контента (7.4) [17] не рекомендуют создавать автоматически обновляемые страницы, поскольку большинство веб-браузеров не позволяют пользователю отключать или контролировать частоту обновления. Некоторые статьи, написанные ими по этой проблеме, включают Рекомендации W3C по обеспечению доступности веб-контента (1.0): Обеспечьте пользователю контроль над изменениями контента, зависящими от времени. Используйте стандартные перенаправления: не нажимайте кнопку «Назад»! [18] и «Основные методы обеспечения доступности веб-контента», раздел 7. [19]

Перенаправления JavaScript

JavaScript может вызвать перенаправление, установив window.locationатрибут, например:

окно . местоположение = 'https://www.example.com/'

Обычно JavaScript помещает URL-адрес сайта-перенаправителя в историю браузера. Это может вызвать циклы перенаправления, когда пользователи нажимают кнопку «Назад». С помощью следующей команды вы можете предотвратить такое поведение. [20]

окно . расположение . заменить ( 'https://www.example.com/' )

Однако HTTP-заголовки или метатег обновления могут быть предпочтительными по соображениям безопасности, а также потому, что некоторые браузеры и многие веб-сканеры не выполняют JavaScript .

Перенаправление кадров

Немного другого эффекта можно добиться, создав встроенный фрейм :

< iframe  height = "100%"  width = "100%"  src = "https://www.example.com/" >
Перейдите по < a  href = "https://www.example.com/" > ссылке < / а > . </ iframe >

Одним из основных отличий от вышеуказанных методов перенаправления является то, что при перенаправлении фрейма браузер отображает URL-адрес документа фрейма, а не URL-адрес целевой страницы в строке URL-адреса. Эту технику маскировки можно использовать для того, чтобы читатель увидел более запоминающийся URL-адрес или чтобы обманным путем скрыть фишинговый сайт в рамках подделки веб-сайта . [21]

До появления HTML5 [22] тот же эффект можно было сделать с помощью HTML-фрейма , содержащего целевую страницу:

< frameset  rows = "100%" >  < frame  src = "https://www.example.com/" >  < noframes >  < body > Следуйте < a  href = "https://www.example.com/" > ссылка </ а > . </body> </noframes> </frameset> _ _ _ _ _ _

Цепочки редиректов

Одно перенаправление может привести к другому в цепочке перенаправлений. Если перенаправление приводит к другому перенаправлению, это также может называться двойным перенаправлением. [23] Например, URL-адрес «https://wikipedia.com» (с доменом «*.com») сначала перенаправляется на https://www.wikipedia.org/ (с именем домена в .org ), где вы можете перейти на сайт, посвященный конкретному языку. Это неизбежно, если разные ссылки в цепочке обслуживаются разными серверами, хотя это следует свести к минимуму, переписав URL-адрес как можно больше на сервере, прежде чем возвращать его браузеру в качестве перенаправления.

Циклы перенаправления

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

Стандарт HTTP/1.1 гласит: [24]

Клиент ДОЛЖЕН обнаруживать и вмешиваться в циклические перенаправления (т. е. «бесконечные» циклы перенаправления).

Примечание. Более ранняя версия этой спецификации рекомендовала максимум пять перенаправлений ([RFC 2068], раздел 10.3). Разработчики контента должны знать, что некоторые клиенты могут реализовать такое фиксированное ограничение.

Услуги

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

Службы перенаправления URL-адресов

Служба перенаправления — это система управления информацией, которая предоставляет интернет-ссылку, которая перенаправляет пользователей на желаемый контент. Типичным преимуществом для пользователя является использование запоминающегося доменного имени и сокращение длины URL-адреса или веб-адреса. Ссылку перенаправления также можно использовать в качестве постоянного адреса для контента, который часто меняет хосты, аналогично системе доменных имен . Гиперссылки, включающие службы перенаправления URL-адресов, часто используются в спам-сообщениях, направляемых в блоги и вики. Таким образом, один из способов уменьшить количество спама — отклонить все изменения и комментарии, содержащие гиперссылки на известные службы перенаправления URL-адресов; однако это также приведет к удалению законных изменений и комментариев и может оказаться неэффективным методом уменьшения количества спама. Недавно службы перенаправления URL-адресов стали использовать AJAX как эффективный и удобный для пользователя метод создания сокращенных URL-адресов. Основным недостатком некоторых служб перенаправления URL-адресов является использование страниц задержки или рекламы на основе кадров для получения дохода.

История

Первые службы перенаправления использовали домены верхнего уровня (TLD), такие как « .to » (Тонга), « .at » (Австрия) и « .is » (Исландия). Их целью было создать запоминающиеся URL-адреса. Первым массовым сервисом перенаправления был V3.com, который на пике своего развития в 2000 году имел 4 миллиона пользователей. Успех V3.com объяснялся наличием большого количества коротких запоминающихся доменов, включая «r.im», «go.to», «i». .am», «come.to» и «start.at». V3.com был приобретен FortuneCity.com, крупной компанией бесплатного веб-хостинга, в начале 1999 года. [25] Поскольку цена продажи доменов верхнего уровня начала падать с 50 долларов США в год до менее 10 долларов США , использование услуг перенаправления сократилось. С запуском TinyURL в 2002 году появился новый вид службы перенаправления, а именно сокращение URL-адресов . Их целью было сделать длинные URL-адреса короткими, чтобы можно было размещать их на интернет-форумах. С 2006 года, когда в чрезвычайно популярном сервисе Twitter было установлено ограничение в 140 символов , эти службы коротких URL-адресов стали активно использоваться.

Маскировка реферера

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

Вот упрощенный пример такого сервиса, написанный на PHP .

<?php $url  =  htmlspecialchars ( $_GET [ 'url' ]); заголовок ( 'Обновить: 0; url=https://'  .  $url ); ?> <!-- Резервный вариант с использованием метаобновления. --> <html> <head> <title> Перенаправление ... </title> < meta http -equiv = " refresh " content = "0 ; url=https:// < ? = $ url ; ? > " > </ head > < body > Попытка перенаправления на < a href = "https:// <? = $url ; ?> " > https:// <? = $ URL ; ?> </ а > . </ тело > </ html >

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

Проблемы с безопасностью

Перенаправление URL-адресов может быть использовано злоумышленниками для фишинговых атак, таких как открытое перенаправление и скрытое перенаправление . «Открытое перенаправление — это приложение, которое принимает параметр и перенаправляет пользователя на значение параметра без какой-либо проверки». [26] «Скрытое перенаправление — это приложение, которое принимает параметр и перенаправляет пользователя на значение параметра БЕЗ ДОСТАТОЧНОЙ проверки». [27] Об этом сообщил в мае 2014 года аспирант-математик Ван Цзин из Наньянского технологического университета в Сингапуре. [28]

Смотрите также

Рекомендации

  1. ^ ab «Google возрождает отслеживание перенаправления» . Блог.anta.net . 29 января 2009 г. ISSN  1797–1993. Архивировано из оригинала 17 августа 2011 года.
  2. ^ «Перенаправления и SEO — полное руководство» . Аудисто . Проверено 29 ноября 2015 г.
  3. ^ «Совет по SEO: обсуждение 302 редиректов» . Мэтт Каттс, бывший руководитель группы Google по борьбе со спамом. 4 января 2006 г.
  4. ^ «Подлые перенаправления». Google Inc., 3 декабря 2015 г.
  5. ^ «Шпаргалка по непроверенным перенаправлениям и переадресациям» . Открытый проект безопасности веб-приложений (OWASP). 21 августа 2014 г.
  6. ^ «Перенаправления и SEO — Полное руководство» . Аудисто . Проверено 29 ноября 2015 г.
  7. ^ «Перенаправления PHP: с 302 по 301 Надежное решение» . WebSiteFactors.co.uk. Архивировано из оригинала 12 октября 2012 года.
  8. ^ Рой Т. Филдинг; Джулиан Ф. Решке, ред. (2014). "Расположение". Протокол передачи гипертекста (HTTP/1.1): семантика и содержание. IETF . п. 68. сек. 7.1.2. дои : 10.17487/RFC7231 . РФК 7231.
  9. ^ Бернерс-Ли, Тим ; Филдинг, Рой Т .; Масинтер, Ларри (2005). «Справочное разрешение». Единый идентификатор ресурса (URI): общий синтаксис. IETF . п. 28. сек. 5. дои : 10.17487/RFC3986 . РФК 3986.
  10. ^ «Модуль ngx_http_rewrite_module — переписать» . nginx.org . Проверено 24 декабря 2014 г.
  11. ↑ Муренин, Константин А. (18 февраля 2013 г.). «Динамический веб-сайт, полностью написанный на nginx.conf? Представляем mdoc.su!». [email protected] (список рассылки) . Проверено 24 декабря 2014 г.
  12. ^ Муренин, Константин А. (23 февраля 2013 г.). «mdoc.su — URL-адреса кратких страниц руководства для FreeBSD, OpenBSD, NetBSD и DragonFly BSD» . Проверено 25 декабря 2014 г.
  13. ^ Муренин, Константин А. (23 февраля 2013 г.). «mdoc.su.nginx.conf» . Проверено 25 декабря 2014 г.
  14. ^ «Метатег HTML» . www.w3schools.com .
  15. ^ «Исследование динамических документов». 2 августа 2002 г. Архивировано из оригинала 2 августа 2002 г.{{cite web}}: CS1 maint: bot: исходный статус URL неизвестен ( ссылка )
  16. ^ «Google и Yahoo принимают незадерживаемые метаобновления как 301 редирект» . Брошюры Себастьяна. 3 сентября 2007 г.
  17. ^ «Руководство по обеспечению доступности веб-контента 1.0» . www.w3.org .
  18. ^ Команда, QA. «Использовать стандартные редиректы». www.w3.org .
  19. ^ «Основные методы обеспечения доступности веб-контента 1.0» . www.w3.org .
  20. ^ «Кроссбраузерный генератор перенаправления URL-адресов на стороне клиента» . Инсайдерская зона. Архивировано из оригинала 26 июля 2020 года . Проверено 27 августа 2015 г.
  21. ^ Аарон Эмиг (19 января 2005 г.). «Технология защиты от фишинга». Архивировано 27 сентября 2007 г. в Wayback Machine (PDF). Радикс Лабс.
  22. ^ «HTML 5.2: 11. Устаревшие функции» . www.w3.org .
  23. ↑ Шварц, Барри (18 декабря 2007 г.). «Двойные редиректы могут занять у Google больше времени, чтобы их обработать». Круглый стол по поисковым системам . Проверено 28 января 2024 г.
  24. ^ Рой Т. Филдинг ; Джулиан Ф. Решке, ред. (2014). «Перенаправление 3хх». Протокол передачи гипертекста (HTTP/1.1): семантика и содержание. IETF . п. 54. сек. 6.4. дои : 10.17487/RFC7231 . РФК 7231.
  25. ^ «Чистая прибыль крошечной тихоокеанской страны» . Новости BBC . 14 сентября 2007 г. Архивировано из оригинала 12 мая 2014 г. Проверено 27 мая 2010 г.
  26. ^ «Открыть перенаправление». ОВАСП. 16 марта 2014 года . Проверено 21 декабря 2014 г.
  27. ^ «Скрытое перенаправление». Тетраф. 1 мая 2014 года . Проверено 21 декабря 2014 г.
  28. ^ «Обнаружен серьезный недостаток безопасности в OAuth, OpenID» . CNET. 2 мая 2014 года . Проверено 21 декабря 2014 г.

Внешние ссылки