URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним URL адресом. HTTP предоставляет специальный вид ответов, HTTP redirect , для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.
В HTTP, перенаправление вызывается при отправке сервером специального ответа на запрос: redirects. HTTP перенаправление, это ответы с кодом статуса 3xx . Когда браузер получает ответ перенаправления, он использует новый предоставленный URL-адрес и немедленно загружает его: в большинстве случаев переадресация невидима для пользователя, за исключением небольшого влияния производительность.
Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.
Эти перенаправления призваны длиться вечно. Они подразумевают, что оригинальный URL-адрес больше не должен использоваться, а вместо него должен быть использован новый. Поисковые роботы запускают обновление связанного URL-адреса для ресурса в своих индексах.
Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.
Иногда, доступ к запрашиваемому ресурсу не может быть предоставлен из определенного места, но может быть предоставлен из другого. В этом случае, могут быть использованы временные перенаправления. Поисковые роботы не запоминают новую, временную ссылку. Временные перенаправления также используются, когда создаются, обновляются, или удаляются ресурсы, которые представляют временные страницы.
| Код | Текст | Обработка метода | Случаи использования |
|---|---|---|---|
| 302 | Found | GET методы неизменны. Другие методы могут быть превращены в GET . |
Веб-страница недоступна по непредвиденым причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. |
| 303 | See Other | GET методы неизменны. Другие превращены в GET (тело запроса теряется). |
Используется для перенаправления после PUT или POST для предотвращения обновления страницы, что может спровоцировать повторный вызов операции. |
| 307 | Temporary Redirect | Метод и тело запроса неизменны. | Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. Лучше чем код 302 когда не-GET ссылки/операции доступны на сайте. |
Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.
В добавок к обычным перенаправлениям, есть 2 специальные. Перенаправление с кодом (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.
HTTP перенаправления это не единственный способ переадресации. Есть еще два метода: HTML перенаправления используют элемент , и JavaScript перенаправления используют DOM .
HTTP перенаправления более предпочтительный способ создания перенаправлений, но, иногда, у веб-разработчиков нету контроля над сервером или возможности настроить его. Для таких особых случаев, разработчики могут создать HTML страницу с элементом и установить атрибуту http-equiv значение refresh в блоке элемент предоставляет общую информацию (метаданные) о документе, которая включает в себя заголовок и ссылки на скрипты и стили.">
. Когда страница отображается, браузер найдет этот элемент и перейдет на указанную страницу.
URL http://example.com/ будет переенаправлен к http://www.example.com/ (но не к http://example.com/other.html)
Redirect_Match делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:
RedirectMatch ^/images/(.*)$ http://images.example.com/$1
Все документы в папке images/ будут перенаправляться к другому домену.
Если вы не хотите устанавливать временное перенаправление, дополнительный параметр (используйте или код статуса HTTP, или ключевое слово permanent) может использоваться чтобы установить другое перенаправление:
Redirect permanent / http://www.example.com Redirect 301 / http://www.example.com
Также модуль mod_rewrite может использоваться для создания перенаправлений. Они более гибкие, но сложнее в использовании.
В Nginx, вы создаете особый серверный блок для контента, который вы хотите перенаправлять:
Server { listen 80; server_name example.com; return 301 $scheme://www.example.com$request_uri; }
Чтобы применить перенаправления к папке или подмножеству страниц, используйте директиву rewrite:
Rewrite ^/images/(.*)$ http://images.example.com/$1 redirect; rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
В IIS, вы используете элемент
Циклы перенаправлений случаются когда за успешным перенаправлением следует другое, которое уже было выполнено. Другими словами, существует такой цикл, который никогда не закончится и в конечном счете ни одна страница не будет найдена.
В большинстве случаев это проблема сервера, и если сервер не может обнаружить её, то отправит код статуса Internal Server Error . Если вы встретите такую ошибку вскоре после редактирования настроек сервера, то это скорее всего цикл перенаправлений.
В случае, когда сервер не может обнаружить его: цикл перенаправлений может распространиться на несколько серверов, каждый из которых не имеет полной картины происходящего. В этом случае, браузеры покажут сообщение об ошибке. Firefox выведет:
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
тогда, как Chrome:
This Webpage has a redirect loop
В обоих случаях, пользователь не может ничего сделать (в отличие от ошибки на стороне клиента, например, несоответствие файлов куки или кеша).
Важно избегать циклов перенаправлений, так как они полностью нарушают работу пользователя.
По-английски расшифровывается как Uniform Resource Locator, что в переводе на русский язык обозначает «единый указатель ресурсов». По-русски эту аббревиатуру обычно произносят как «у-эр-эл», «ю-ар-эл», или просто «урл». Попробуем разобраться подробнее в том, что такое URL. Каждый документ (веб-страница) в сети Интернет имеет определенное местонахождение, на которое можно точно указать. С помощью URL адреса как раз и указывается точный путь к определенной вебстранице. Аналогично тому, как указывается путь к любому файлу на компьютере, URL адрес строится по определенной схеме, которая обычно выглядит приблизительно так:
http://name.ru/papka/document.html
Где http - указывает на тип протокола, по которому осуществляется передача данных, name.ru - означает доменное имя сайта, papka представляет собой папку, а document.html - конкретную страницу, на которую и ведет данный URL адрес.
Поскольку наш URL адрес http://name.ru/papka/document.html является вымышленным, дается только для примера, и, соответственно, ни к какой вебстранице не ведет, то, попытавшись перейти по нему, мы попадем на страницу, содержащую информацию об ошибке. Выглядеть она может по-разному, однако мы обязательно встретим надпись «404 not found ». «Not found» в переводе означает «не найдено», а появление страницы 404 означает, что URL адрес вебстраницы был введен не полностью, неверно (с ошибкой или опечаткой), либо запрошенная страница больше не находится по данному адресу, так как была удалена или переименована.
Ошибка 404 часто возникает при переходе по ссылке, найденной на другой странице, в том случае, если ссылка является устаревшей. Автор сайта мог переместить нужный нам документ, переименовать его или удалить. Что же делать, если при переходе возникает 404 страница? Во-первых, проверить правильность URL адреса, если он нам известен. Исправить ошибки или опечатки и попробовать перейти снова. Если же ошибка 404 возникает при переходе по ссылке на незнакомый ресурс, следует попробовать перейти на главную и воспользоваться поиском по сайту - возможно, что нужная информация все же найдется.
Кстати, многие разработчики сайтов заботятся о том, чтобы страница 404 на их сайте не выглядела устрашающе безнадежно. Здесь размещают юмористический текст с забавной картинкой, чтобы подбодрить заблудившегося пользователя, а также ссылки на главную сайта, строку поиска либо карту сайта. Если страница 404 выглядит недружелюбно и ссылок для перехода на ней нет, можно попробовать вручную сократить URL адрес, оставив только имя сайта - в нашем примере это будет http://name.ru/ и таким образом попытаться попасть на главную страницу сайта, откуда можно будет перейти на искомую страницу.
HTTP - это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.
Давайте взглянем на этот протокол через призму нашей профессии. В первой части пройдёмся по основам, посмотрим на запросы/ответы. В следующей статье разберём уже более детальные фишки, такие как кэширование, обработка подключения и аутентификация.
Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.
HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.
В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.
Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.
Текущая версия протокола HTTP - 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.
Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:
Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию - 80. Далее следует путь к ресурсу на сервере и цепочка параметров.
С помощью URL, мы определяем точное название хоста, с которым хотим общаться, однако какое действие нам нужно совершить, можно сообщить только с помощью HTTP метода. Конечно же существует несколько видов действий, которые мы можем совершить. В HTTP реализованы самые нужные, подходящие под нужды большинства приложений.
Существующие методы:
GET : получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.
POST : используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.
PUT : обновить текущий ресурс. PUT запрос содержит обновляемые данные.
DELETE : служит для удаления существующего ресурса.
Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.
Также HTTP поддерживает и другие методы:
HEAD : аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.
TRACE : во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.
OPTIONS : используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.
В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:
1xx: Информационные сообщения
Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.
2xx: Сообщения об успехе
Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант - это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:
3xx: Перенаправление
Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.
4xx: Клиентские ошибки
Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:
5xx: Ошибки сервера
Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:
На следующем изображении вы можете увидеть схематично оформленный процесс отправки запроса клиентом, обработка и отправка ответа сервером.
Давайте посмотрим на структуру передаваемого сообщения через HTTP:
Message =
Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:
Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.
Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:
General-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning
Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.
Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.
Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache - это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.
Заголовок Date используется для хранения даты и времени запроса/ответа.
Заголовок Upgrade используется для изменения протокола.
Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.
В заголовках сущностей передаётся мета-информация контента:
Entity-header = Allow | Content-Encoding | Content-Language | Content-Length | Content-Location | Content-MD5 | Content-Range | Content-Type | Expires | Last-Modified
Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.
Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.
С помощью данных заголовков, можно задать нужную для ваших задач информацию.
Запрос выглядит примерно так:
Request-Line = Method SP URI SP HTTP-Version CRLF Method = "OPTIONS" | "HEAD" | "GET" | "POST" | "PUT" | "DELETE" | "TRACE"
SP - это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:
GET /articles/http-basics HTTP/1.1 Host: www.articles.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Список возможных заголовков запроса:
Request-header = Accept | Accept-Charset | Accept-Encoding | Accept-Language | Authorization | Expect | From | Host | If-Match | If-Modified-Since | If-None-Match | If-Range | If-Unmodified-Since | Max-Forwards | Proxy-Authorization | Range | Referer | TE | User-Agent
В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.
Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Обычный статус выглядит примерно так:
HTTP/1.1 200 OK
Заголовки ответа могут быть следующими:
Response-header = Accept-Ranges | Age | ETag | Location | Proxy-Authenticate | Retry-After | Server | Vary | WWW-Authenticate
Думаю, на сегодня теории достаточно. Теперь давайте взглянем на инструменты, которыми мы можем пользоваться для мониторинга HTTP сообщений.
Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:
Наиболее часто используемый - это Chrome Developers Tools:
Если говорить об отладчике, можно воспользоваться Fiddler :
Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.
Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте .
Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().
$.ajax({ url: "http://www.articles.com/latest", type: "GET", beforeSend: function (jqXHR) { jqXHR.setRequestHeader("Accepts-Language", "en-US,en"); } });
Если хотите обработать статус запроса, то это можно сделать так:
$.ajax({ statusCode: { 404: function() { alert("page not found"); } } });
Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.
В начале каждого семестра студенты магистерской программы кафедры МиИТ Академического университета (СПб) и представители компаний-партнеров собираются вместе. Представители рассказывают о проектах, над которыми можно будет работать, а студенты выбирают их.
В одном из проектов, сделанных в Parallels Labs , наш студент исследовал возможность реализации виртуального Hardware Security Module (HSM) . В результате он добавил свою реализацию VHSM в open-source проект OpenVZ . Подробнее о его решении читайте под катом.
Чтобы начать использовать HSM, пользователь должен себя аутентифицировать. Если аутентификация выполняется через приложение-клиент HSM, работающее в уязвимой части системы, то возможен перехват пароля HSM злоумышленником. Перехваченный пароль даст возможность злоумышленнику использовать HSM без получения секретных данных, хранящихся в нем. Таким образом, аутентификацию желательно выполнять в обход уязвимой части системы, например, при помощи физического ввода PIN.
Основным барьером в использовании HSM является их высокая стоимость. В зависимости от класса устройства цена может варьироваться от 10$ (USB токены, smart карты) до 30000+$ (устройства с аппаратным ускорением криптографии, защитой от взлома, high availability функциями). Провайдеры cloud решений не оставили без внимания рынок HSM. Например, Amazon продает свой облачный HSM по средней цене 1373$ в месяц.
Одной из основных особенностей HSM является изоляция уязвимой части системы, использующей криптографические сервисы, от HSM, исполняющей эти сервисы. Заметим, что отдельные инстансы (виртуальные машины, контейнеры и т.д.), в облаке изолированы друг от друга, поэтому если вынести функции HSM за пределы уязвимого инстанса в другой изолированный от внешнего мира инстанс, то мы достаточно точно воспроизведем функциональность физического HSM. Такой подход мы назвали Virtual HSM (VHSM) . Рассмотрим как он был реализован нашим студентом для проекта OpenVZ .
Пользователь регистрируется в VHSM администратором, в роли которого может выступать как человек, так и программа. При регистрации пользователя VHSM генерирует 256-битный ключ аутентификации и шифрует его мастер ключом с помощью AES-GCM . Далее, перед использованием VHSM, пользователь аутентифицирует себя парой логин-пароль. Во время аутентификации, мастер-ключ, сформированный из пароля и соли, используется для расшифровывания ключа аутентификации пользователя. Использование GCM позволяет проверить правильность мастер-ключа при расшифровке. Мастер-ключ получается из пароля пользователя, и потому проверка его правильности позволяет проверить и сам пароль пользователя, переданный при аутентификации. После успешной аутентификации пользователю становятся доступны криптографические сервисы, использующие хранящиеся в VHSM цифровые ключи пользователя.
VHSM требует явного выбора контейнеров, из которых конкретный пользователь может работать с VHSM. Информация о контейнере, из которого получена команда пользователя, предоставляется OpenVZ.
Утечка БД из VHSM VE не приведет к немедленной утрате секретных данных, т.к. они хранятся в зашифрованном виде. Ключ шифрования не хранится в БД, а генерируется из пароля пользователя, передающегося при его аутентификации.
Как и любая технология защиты иформации, приведенное решение является еще одним барьером на пути злоумышленника и не обеспечивает полной защиты информации.
Многие слышали о понятии URL адреса, но немногие знают, зачем он нужен и что собой представляет.
Поэтому было бы полезно разобрать несколько вопросов, связанных с темой «URL адрес» – что это такое, где используется, какова структура и другие интересные моменты.
На самом деле, если вы хоть раз в жизни заходили в интернет, значит, пользовались URL адресом. Все намного проще, чем может казаться на первый взгляд.
URL адрес – это адрес какого-либо ресурса в интернете.
Под понятием «ресурс» в прошлом предложении имеется в виду сайт, изображение, документ или что-либо еще, что только может находиться в интернете на каком-то удаленном сервере.
Существует также chrome, который действует подобным образом. Все же чаще всего мы, обычные пользователи, используем самый обычный http.
Разработчики пользуются ftp и подобными ему специализированными протоколами.
Теперь перейдем непосредственно к примеру. Возьмем одну из статей на этом сайте и ссылку на нее – (кстати, очень неплохая статья).
Так вот, как видим, здесь все соответствует описанное выше структуре.
Параметр <способ> здесь http, после него идет стандартная конструкция «://»..
Все, что касается хоста – логин и пароль – обычному пользователю не видно. И после «/» идет непосредственно адрес нужной статьи, это уже параметр <путь>.
Никаких дополнительных параметров здесь нет.
Вот так, собственно, и выглядит любой URL адрес в мире.
Интересно, что многие не знают, где взять этот самый URL адрес. Конечно, если речь идет о сайте, то его можно посмотреть в адресной строке.
Для примера возьмем ту же описанную выше статью.
На рисунке №2 показано расположение ее адреса в браузере.
Стоит отметить, что в браузере обычно не указывается параметр <способ> из вышеуказанной структуры.
Как видим, и на рисунке №2 рядом с началом адреса нет надписи «http». Это вполне нормально. Обычно данный параметр становится видным уже после копирования данного адреса в буфер .
Кстати, копирование здесь происходит вполне стандартным способом – нажатием сочетания клавиш Ctrl +C .
Второй способ заключается в том, чтобы выделить соответствующий текст, нажать на него правой кнопкой мыши и в выпадающем меню выбрать пункт «Копировать», как это показано на рисунке №3.
Но, как мы говорили выше, URL адрес есть не только у целых сайтов, а и у отдельных файлов, таких как изображения и документы.
Чтобы узнать их URL, тоже можно нажать на соответствующий файл, к примеру, картинку, правой кнопкой мыши и в меню выбрать пункт «Копировать адрес изображения», как это показано на рисунке №4.
Если речь все-таки идет о документе, на него тоже всегда можно кликнуть правой кнопкой мыши, после чего увидеть выпадающее меню и в нем выбрать пункт «Копировать адрес ссылки», как это показано на рисунке №5.
Внимание: В приведенных выше рисунках показано выпадающее меню в браузере Opera. В зависимости от браузера внешний вид данного меню может меняться. Но названия нужных нам пунктов практически всегда остаются неизменными.
Собственно, это и есть способ, как узнать адрес того или иного ресурса.
Как видим, в конце находится расширение файла – .jpg. После параметра <хост> здесь после «/» идет многоуровневый адрес доступа к фотографии.
Такой адрес означает, что картинка с названием «kak-v-vk-zakrepit-zapis-na-stene-%E2%84%9611-650×406.jpg» находится на хосте сайт в папке под названием «wp-content», внутри которой находится папка «uploads», внутри неё «2016», а в ней еще и папка «03».
В принципе, в данном адресе все предельно ясно. Вопросы вызывает лишь вот эта конструкция: «%E2%84%9611». Это зашифрованный фрагмент адреса.
Итак, где взять этот адрес сайта или иного ресурса, мы уже разобрались. Но иногда при копировании, к примеру, вот такого: «https://ru.wikipedia.org/wiki/Смартфон » копируется что-то вот такое:
Не углубляясь в недра познания мира сего, скажем, что все URL адреса записываются только с помощью определенного набора символов.
И кириллица в него, как мы понимаем, не входит. Поэтому, чтобы машина могла понять, куда ей следует обращаться, происходит шифрование.
Делается это в два этапа:
В более современных браузерах имеет место сначала кодирование в Base58.
Каждый байт разделяется знаком процента, то есть «%». Собственно, этим и обуславливается то, что мы можем видеть выше.
Современные браузеры уже не дают пользователю видеть ссылки с шестнадцатеричными цифрами.
Поэтому если вы копируете ссылку в нормальном виде, а получаете что-то вроде «https://ru.wikipedia.org/wiki/%D0%A1%D0%BC%D0%B0%D1%80%D1%82%D1%84%D0%BE%D0%BD», просто обновите свой браузер !
История создания URL адресов довольно интересная.
А затронем мы эту область для того, чтобы лучше понимать, что собой представляют данные конструкции и зачем были созданы.
Хотя, из вышесказанного уже можно понять, что URL представляет собой адрес ресурса в интернете, а создан он был для того, чтобы этот ресурс банально можно было в нем найти.
Но интересно, что впервые про URL заговорили в Женеве. А изобретателем его считается Тим Бернерс-Ли.
Случилось сие событие в 1990 году – намного позже, чем могло бы показаться на первый взгляд.
Сначала URL использовали для того, чтобы обозначать расположение отдельных файлов в интернете, но потом специалисты поняли, что это очень удобно и стали применять его для обозначения практически всех возможных ресурсов интернета.
Постепенно на смену URL пришел так называемый URI. Согласно учебнику по сетям, эта конструкция тоже представляет собой символьное определение ресурса.
В URL входит, во-первых, имя сайта, а во-вторых, его расположение.
Существует также URN – это или только адрес сайта/ресурса, или его имя. URI же объединяет в себе URL и URN.
Изобретена была такая конструкция в том же 1990 году, что и ее прародитель, URL.
Хотя завершение работы над ней датируется аж 1994 годом. В 1998 году вышла новая версия URI.
В 2002 году было сообщено о том, что термин URL устарел и лучше использовать вместо него только URI.
Таким образом, самые использованные способы обозначения расположения файлов в интернете берут свое начало в Женеве, а конкретно в Европейском совете по ядерным исследованиям или просто CERN.
Последнее более известно тем, кто хоть иногда смотрит новости.
У современного URL есть огромное количество недостатков, среди них:
По этим и другим причинам была предложена совершенно новая интерпретация URL под названием PURL.
В рамках данного стандарта будет использоваться несколько иной подход.
Все будет основано на существовании базы данных PURL, в которой и будут храниться все имена и пути к ресурсам.
Система будет регулярно проверять эти ресурсы и, при необходимости, удалять или обновлять ссылки на них. Таким образом удастся решить три из пяти вышеперечисленных проблем.
Что касается остальных, специалисты пока что находятся на стадии разработки их решений.
Ниже можно видеть весьма интересный и занятный ролик про интернет в принципе.
Его просмотр позволит еще в большей степени понять, что вообще такое URL, и какое место эта конструкция занимает в работе Всемирной паутины.
URL адрес страницы сайта: Что это такое и где его взять?
