Предыдущие части: Основы HTML, Виртуальные хосты, IP-адреса и DNS, Ставим Apache, Порты и сокеты, Введение
Рассмотрим ещё один способ формирования разделов сайта. В нашем примере сайт test содержит страницы index.html, news.htm, about.html и т.д., и все они расположены в корневой папке документов.
Адреса этих страниц будут выглядеть так:
- http://test/ (index.html не пишем)
- http://test/news.html
- http://test/about.html
Мы можем создать в корневой папке новые папки: news и about. И переложить файл news.html в папку news, а файл about.html в папку about. Так как теперь эти файлы лежат каждый в своей папке, их можно переименовать в index.html. Теперь адреса страниц будут выглядеть так:
- http://test/ (index.html не пишем)
- http://test/news/ (index.html не пишем)
- http://test/about/ (index.html не пишем)
Знак "/" в конце можно не писать, но с ним более понятно, что мы обращаемся не к файлу, а к папке сайта. Браузер запрашивает имя папки и веб-сервер отдаёт ему файл index.html из этой папки, потому что он настроен его отдавать, когда имя файла не указано.
Смотрите: у нас есть веб-сервер, мы умеем оформлять HTML-файлы и делать ссылки. Этого достаточно, чтобы смастерить статический сайт из нескольких страниц. Почему он называется статическим? Потому что браузер просто запрашивает у сервера файл, а сервер отдаёт ему файл. Файл создан один раз и просто лежит на диске. Ничего не меняется.
Статический сайт прекрасно подходит для того, чтобы, например, написать свою биографию. Ведь факты биографии если и будут меняться, то редко.
Но что, например, происходит, когда мы заходим в Яндекс и ищем какую-нибудь строку? Хотя адрес сайта каждый раз один и тот же, информация, которую мы получаем – разная, и зависит от нашего поискового запроса.
Очевидно, что веб-сервер также получает нашу поисковую строку. Как?
Откройте эту ссылку: https://yandex.ru/search/
Куда мы собственно попали? В адресе мы указали не просто имя сервера yandex.ru, но и папку на нём: yandex.ru/search/. Это имя папки, очевидно, ведёт нас конкретно на результаты поиска, а не просто на сайт. Мы видим сообщение "Задан пустой поисковый запрос", потому что действительно не передавали ничего для поиска.
Теперь откройте такую ссылку, а лучше не ленитесь и напечатайте её руками в адресной строке: https://yandex.ru/search?text=Java
И вот мы уже видим результаты поиска по слову Java.
Получается, мы передали поисковый запрос прямо через адрес сайта. Посмотрим на него ещё раз. Сразу же выделяется выражение text=Java. Очень похоже на самое обычное присвоение переменной, не правда ли? Стало быть, параметру "text" присвоено значение "Java". А всё выражение записано в адресной строке после знака "?".
Этот знак служит разделителем между адресом сайта и передаваемыми параметрами.
Всё это – и "http://", и имя сайта, и знак "?" – части структуры, которая называется URL – Uniform Resource Locator, или Универсальный Указатель Ресурса. Для краткости мы говорим просто "адрес", но его функционал несколько больше. Весь его мы прямо сейчас рассматривать не будем. Пока посмотрим на уже известные части структуры:
[протокол]//[имя сайта]/[путь к файлу или папке]?[поисковый запрос]
Вот такой URL веб-сервер и получает целиком. Из него он может понять: к какому сайту мы обращаемся (на машине может одновременно жить несколько разных сайтов), какой файл или папку с этого сайта запрашиваем, и наконец, какой поисковый запрос передаём.
Поисковый запрос не является чем-то магическим. И вообще говоря, он только по историческим причинам называется запросом (query), а на деле это просто набор параметров и их значений, которые доставляются от нас к веб-серверу и могут использоваться для любых целей. Или не использоваться вообще.
Например, мы можем обратиться к Яндексу с таким URL:
https://yandex.ru/search/?trololo=azazaz
Мы передали Яндексу параметр "trololo" со значением "azazaz". И в результате получили всего лишь пустую поисковую страницу. Потому что Яндексу начхать, что мы там ему прислали. Он сделает поиск только тогда, когда мы пришлём ему параметр c именем "text".
То есть: веб-сервер Яндекса разбирает URL на части, и если видит там параметр "text", то ищет то, что записано в этом параметре. Если же не видит, то ничего не делает. Хоть обприсылайся.
Через URL можно передать не один параметр, а много. Для этого их нужно просто записать подряд, а между ними поставить разделитель – знак "&". Например, у Яндекса кроме параметра "text" есть ещё параметр "p", это номер страницы результатов. Допустим, мы хотим найти слово "URL" и попасть на 5-ю страницу результатов. Тогда нам надо передать Яндексу два параметра:
- text=URL
- p=4 (счёт страниц у Яндекса идёт с нуля)
Записываем их подряд через разделитель "&":
text=URL&p=4
И подставляем в URL:
https://yandex.ru/search/?text=URL&p=4
И вот Яндекс вернул нам сразу 5-ю страницу результатов поиска по слову "URL":
Если понадобится передать ещё больше параметров, их точно так же можно дописать, используя разделитель "&".
Данный способ передачи параметров на сервер называется GET-запросом. Он играет очень большую роль в работе сайтовых движков, скриптов и прочих программ, работающих на сервере. Поэтому с ним мы столкнёмся не раз.
Но в нём действительно нет ничего сложного – это просто параметры, которые передаются на сервер прямо в URL.
У этого метода есть три недостатка.
1. Внешний вид ссылок
Ссылки на сайты становятся трудночитаемыми. Например, так выглядит ссылка на поиск Google, в которую сам Google включил много параметров:
Но если мы знаем, что Гуглу из этого всего хватит лишь параметра "q" (то же самое, что "text" у Яндекса), то можем просто стереть всё лишнее и оставить только:
https://www.google.com/search?q=URL
Кстати, когда я делюсь ссылками, то всегда убираю из них ненужные параметры. Как по эстетическим соображениям, так и для того, чтобы не давать лишней информации для отслеживания. Например, из вышеприведённого примера видно, что у меня браузер FireFox и отключён безопасный поиск в Гугле.
2. Ограниченная длина запроса
URL не может быть длиннее чем 2 килобайта (2048 байт). Если нужно передать больше данных, GET уже не подойдёт.
3. Безопасность
К передаче параметров в GET-запросе нужно подходить очень тщательно. Первый пример смотрите выше. Обнародовать свой браузер это конечно ни о чём, но в некоторых случаях, на некоторых сайтах, особенно написанных криворукими программистами, в URL может (по случайности или как-то ещё) оказаться и логин и пароль пользователя, и другие его конфиденциальные данные. И всё это легко копируется и распространяется. Вторая опасность – это логирование запросов на сервере. Каждый запрос пишется в файл типа access.log, и естественно, что URL со всеми параметрами попадает в этот файл. Таким образом, даже если вы ни с кем не делились ссылками, ваши личные данные могут оказаться в лог-файле, который кто-то может посмотреть.
Почему GET?
Ну и наконец, почему этот запрос называется GET? Потому что браузер, когда просит у сервера что-то прислать, именно так общается с ним по протоколу HTTP, например:
GET /index.html
А передавая параметры в URL, мы можем не только попросить что-то у сервера, но и отправить ему что-то:
GET /search?text=URL
В следующем выпуске рассмотрим запрос другого типа: POST.
Читайте дальше: