Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

HTTP Кратко: ресурсы HTTP

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called HTTP Succinctly.
HTTP Succinctly: HTTP Messages

Russian (Pусский) translation by Liliya (you can also view the original English article)

HTTP - это протокол, который позволяет нам покупать микроволновые печи от Amazon.com, воссоединиться со старым другом в чате Facebook и смотреть забавные  видео про котов на YouTube. HTTP - это протокол, стоящий за Всемирной паутиной. Он позволяет веб-серверу из дата-центра в Соединенных Штатах отправлять информацию в интернет-кафе в Австралии, где молодой студент может прочитать веб-страницу, описывающую династию Мин в Китае.

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

Мы начнем с изучения ресурсов.

Ресурсы

Возможно, наиболее знакомой частью Интернета является HTTP-адрес. Когда я хочу найти рецепт блюда с брокколи, которое почти никогда не было, тогда я могу открыть свой веб-браузер и ввести http://food.com в адресной строке, чтобы перейти на сайт food.com и найти рецепты. Мой веб-браузер понимает этот синтаксис и знает, что ему нужно сделать HTTP-запрос на сервер с именем food.com. Мы поговорим позже о том, что означает «сделать HTTP-запрос» и все связанные с ним сетевые детали. На данный момент мы просто хотим сосредоточиться на адресе: http://food.com.


Локаторы ресурсов

Адрес http://food.com - это то, что мы называем URL-адресом - единым локатором ресурсов. Он представляет конкретный ресурс в Интернете. В этом случае ресурс является домашней страницей веб-сайта food.com. Ресурсы - это то, с чем я хочу работать в Интернете. Изображения, страницы, файлы и видеоролики - все ресурсы.

Есть миллиарды, если не триллионы, мест для выхода в Интернет - другими словами, есть триллионы ресурсов. У каждого ресурса будет URL-адрес, который я могу использовать для его поиска. http://News.Google.com является другим местом чем http://news.yahoo.com. Это два разных имени, две разные компании, два разных веб-сайта и, следовательно, два разных URL-адреса. Конечно, на одном и том же веб-сайте также будут разные URL-адреса. http://Food.com/Recipe/Broccoli-Salad-10733/ — URL-адрес для страницы с рецептом салата с брокколи, в то время как http://food.com/recipe/grilled-cauliflower-19710/ все еще находится на food.com, но это другой ресурс с описанием рецепта цветной капусты.

Мы можем разбить последний URL на три части:

  1. http, часть перед ://, является то, что мы называем схема URL-адреса. Схема описывает, как получить доступ к определенному ресурсу, и в этом случае он сообщает браузеру использовать протокол передачи гипертекста. Позже мы также рассмотрим другую схему HTTPS, которая является защищенным протоколом HTTP. Вы также можете использовать другие схемы, такие как FTP для протокола передачи файлов, и mailto для адресов электронной почты.

    Все после :// будет специфично для конкретной схемы. Таким образом, юридический URL-адрес HTTP не может быть юридическим URL-адресом mailto - эти два не являются взаимозаменяемыми (что имеет смысл, потому что они описывают разные типы ресурсов).

  2. Food.com является ведущим. Это имя хоста сообщает браузеру имя компьютера, на котором размещен ресурс. Компьютер будет использовать систему владеющих имен (DNS) для перевода food.com в сетевой адрес, а затем он точно узнает, куда отправить запрос на ресурс. Вы также можете указать хост-часть URL-адреса с использованием IP-адреса.
  3. /Recipe/Grilled-cauliflower-19710/ это URL-путь. Хост food.com должен распознавать конкретный ресурс, запрашиваемый этим путем, и реагировать соответствующим образом.

Иногда URL-адрес указывает на файл в файловой системе или жестком диске хоста. Например, URL http://food.com/logo.jpg может указывать на картинку, которая действительно существует на сервере food.com. Однако ресурсы также могут быть динамическими. URL-адрес http://food.com/recipes/brocolli вероятно, это не относится к реальному файлу на сервере food.com. Вместо этого на хосте food.com запускается какое-то приложение, которое будет принимать этот запрос и создавать ресурс, используя контент из базы данных. Приложение может быть создано с использованием ASP.NET, PHP, Perl, Ruby on Rails или других веб-технологий, которые умеют отвечать на входящие запросы, создавая HTML для отображения браузера.

Фактически, в наши дни многие веб-сайты пытаются избежать наличия какого-либо реального имени файла в своем URL-адресе. Во-первых, имена файлов обычно связаны с определенной технологией, например .aspx для технологии Microsoft ASP.NET. Многие URL-адреса переживут технологию, используемую для размещения и обслуживания. Во-вторых, многие сайты хотят размещать ключевые слова в URL-адресе (например, иметь /recipe/broccoli/ в URL-адресе для рецепта брокколи). Наличие этих ключевых слов в URL-адресе - это форма поисковой оптимизации (SEO), которая будет оценивать ресурс выше в результатах поисковой системы. В наши дни для URL-адресов важны описательные ключевые слова, а не имена файлов.

Некоторые ресурсы также заставят браузер загружать дополнительные ресурсы. Домашняя страница food.com будет включать в себя изображения, файлы JavaScript, CSS и другие ресурсы, которые будут объединены, чтобы представить «домашнюю страницу» food.com.

Figure 1 foodcom home page

Домашняя страница Food.com 

Порты, строки запросов и фрагменты

Теперь, мы знаем о URL-адрес схемы, хосты и пути, также посмотрим на URL-адрес с номером порта:

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

Все после ? (вопросительный знак) известен как запрос. Запрос, также называемый строкой запроса, содержит информацию для целевого веб-сайта для использования или интерпретации. Не существует формального стандарта того, как строка запроса должна выглядеть так, как это технически зависит от приложения, чтобы интерпретировать найденные значения, но вы увидите, что большинство строк запроса используют для передачи пар имя-значение в форме name1=value&name2=value2.

Например:

В этом примере есть две пары имя-значение. Первая пара имеет имя «первый» и значение «Скотт». Вторая пара имеет имя «последний» со значением «Аллен». В наших предыдущих URL (http://www.bing.com/search?q=broccoli) поисковая система Bing будет отображаться имя «q», связанный со значением «брокколи». Оказывается, Bing ищет значение «q» для использования в качестве условия поиска. Мы можем представить URL-адрес URL-адреса ресурса, который представляет результаты поиска Bing для брокколи.

Наконец еще один URL:

Часть после знака # называется фрагментом. Этот фрагмент отличается от других фрагментов, которые мы рассмотрели до сих пор, поскольку в отличие от пути URL и строки запроса фрагмент не обрабатывается сервером. Фрагмент используется только на клиенте, и он идентифицирует конкретный раздел ресурса. В частности, фрагмент обычно используется для идентификации определенного элемента HTML на странице по идентификатору элемента.

Веб-браузеры обычно выравнивают начальное отображение веб-страницы таким образом, что верх элемента, идентифицированного фрагментом, находится в верхней части экрана. Например URL-адрес http://odetocode.com/Blogs/scott/archive/2011/11/29/programming-windows-8-the-sublime-to-the-strange.aspx#feedback имеет значение фрагмент «обратной связи». Если вы следуете URL-адресу, ваш веб-браузер должен прокрутить страницу вниз, чтобы отобразить раздел обратной связи для определенной записи блога в моем блоге. Ваш браузер получил весь ресурс (сообщение в блоге), но сосредоточил ваше внимание на определенной области - разделе обратной связи. Вы можете представить HTML для сообщения в блоге, который выглядит следующим образом (при этом весь текст опущен):

Клиент гарантирует, что элемент с идентификатором обратной связи находится вверху.

Если мы соединим все, что мы узнали до сих пор, мы знаем, что URL-адрес разбит на следующие части:


URL-кодирование

Все разработчики программного обеспечения, которые работают в Интернете, должны знать о проблемах с кодировкой символов с помощью URL-адресов. Официальные документы, описывающие URL-адреса, имеют большое значение, чтобы сделать URL-адреса доступными и совместимыми, насколько это возможно. URL-адрес должен быть таким же простым для общения по электронной почте, как и для печати на наклейке с бампером и прикрепления к Ford Windstar 2001 года. По этой причине стандарты Интернета определяют небезопасные символы для URL-адресов. Например, символ пробела считается небезопасным, поскольку символы пробела могут ошибочно появляться или исчезать, когда URL-адрес находится в печатном виде (это одно или два пробела на вашей визитной карточке?).

Другие небезопасные символы включают знак числа (#), потому что он используется для разграничения фрагмента и каретки (^), поскольку он не всегда правильно передается через все сетевые устройства. Фактически, RFC 3986 («закон» для URL-адресов) определяет безопасные символы для URL-адресов как буквенно-цифровые символы в US-ASCII, а также несколько специальных символов, таких как двоеточие (:) и знак слэш (/).

К счастью, вы все равно можете передавать небезопасные символы в URL-адресе, но все небезопасные символы должны быть закодированы в процентах (также закодированы в URL). %20 - это кодирование для символа пробела (где 20 - шестнадцатеричное значение для символа пробела US-ASCII).

Например, предположим, вы хотели создать URL-адрес для файла с именем «^ my resume.txt», на someserver.com. Юридический, закодированный URL-адрес будет выглядеть так:

Оба символа ^ и пробела были закодированы в процентах. Большинство инфраструктур веб-приложений предоставят API для простой кодировки URL. На стороне сервера вы должны запускать свои динамически созданные URL-адреса через API-интерфейс кодировки только в том случае, если в URL-адресе появляется один из небезопасных символов.


Ресурсы и типы носителей

До сих пор мы сосредоточились на URL-адресах и упростили все остальное. Но что это значит, когда мы вводим URL-адрес в браузер? Обычно это означает, что мы хотим получить или просмотреть некоторый ресурс. В Интернете есть огромное количество материалов для просмотра, а позже мы также увидим, как HTTP также позволяет нам создавать, удалять и обновлять ресурсы. Пока мы будем сосредоточены на поиске.

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

Чтобы хост правильно обслуживал ресурс, и для того, чтобы клиент мог правильно отображать ресурс, участвующие стороны должны быть конкретными и точными в отношении типа ресурса. Является ли ресурс изображением? Является ли ресурс фильмом? Мы не хотим, чтобы наши веб-браузеры пытались отображать изображение PNG в виде текста, и мы не хотели бы, чтобы они пытались интерпретировать гипертекст как изображение.

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

Чтобы указать типы контента, HTTP опирается на стандарты многопользовательских почтовых расширений (MIME). Хотя MIME изначально был предназначен для электронной почты, HTTP использует стандарты MIME для той же цели, что и для маркировки контента таким образом, чтобы клиент знал, что содержит контент.

Например, когда клиент запрашивает HTML-страницу, хост может ответить на HTTP-запрос некоторым HTML, который он называет как «text/html». «text» часть является основным типом носителя, а «html» - подтипом мультимедиа. При ответе на запрос на изображение хост будет обозначать ресурс типом контента «image/jpeg» для файлов JPG, «image/gif» для файлов GIF или «image/png» для файлов PNG. Эти типы контента являются стандартными типами MIME и в буквальном смысле будут отображаться в ответе HTTP.


Быстрая заметка о расширениях файлов

Вы можете подумать, что браузер будет полагаться на расширение файла, чтобы определить тип содержимого входящего ресурса. Например, если мой браузер запрашивает «frog.jpg», он должен рассматривать ресурс как файл JPG, но лечить «frog.gif» как файл GIF. Тем не менее, для большинства браузеров расширение файла является последним местом, куда оно пойдет, чтобы определить фактический тип контента.

Расширения файлов могут вводить в заблуждение, и только потому, что мы запросили файл JPG, это не означает, что сервер должен отвечать данными, закодированными в формате JPG. Microsoft документирует Internet Explorer (IE), как сначала глядя на тег типа контента, указанный хостом. Если хост не предоставляет тип содержимого, IE затем сканирует первые 200 байтов ответа, пытаясь угадать тип содержимого. Наконец, если IE не находит тип содержимого и не может угадать тип содержимого, он будет отпадать от расширения файла, используемого в запросе ресурса. Это одна из причин, по которой важна метка типа контента, но это далеко не единственная причина.


Согласование содержимого

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

Однако типы носителей не только для хостов. Клиенты могут играть роль в том, какой тип носителя возвращает хост, участвуя в согласовании типа контента.

Ресурс, идентифицированный одним URL, может иметь несколько представлений. Возьмем, к примеру, рецепт брокколи, о котором мы упоминали ранее. Один рецепт может быть на разных языках (английском, французском и немецком). Рецепт мог даже иметь представления в разных форматах (HTML, PDF и обычный текст). Это все тот же ресурс и тот же рецепт, но разные представления.

Очевидный вопрос: какое представление следует выбрать серверу? Ответ заключается в механизме согласования содержимого, описываемом спецификацией HTTP. Когда клиент делает HTTP-запрос на URL-адрес, клиент может указать типы носителей, которые он примет. Типы носителей предназначены не только для того, чтобы хост отмечал исходящие ресурсы, но также и для клиентов, чтобы указать тип носителя, который они хотят использовать.

Клиент указывает, что он примет в сообщении исходящего запроса. Опять же, мы увидим подробности этого сообщения в следующем сеансе, но представьте запрос на http://food.com/ говоря, что он примет представление на немецком языке. Это зависит от сервера в попытке выполнить запрос. Хост может отправить текстовый ресурс, который все еще находится на английском языке, что, вероятно, разочарует немецкоговорящего пользователя, но именно поэтому мы называем его согласованием контента, а не ультиматумом контента.

Веб-браузеры - это сложные программные продукты, которые могут обрабатывать различные типы представлений ресурсов. Согласование контента - это то, что пользователья, никогда не волнует, но для разработчиков программного обеспечения (особенно разработчиков веб-сервисов) согласование контента является частью того, что делает HTTP отличным. Часть кода, написанная на JavaScript, может сделать запрос на сервер и запросить представление JSON. Часть кода, написанная на C ++, может сделать запрос на сервер и запросить представление XML. В обоих случаях, если хост может удовлетворить запрос, информация будет поступать на клиента в идеальном формате для анализа и потребления.


Где мы?

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

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.