HTML и HTTP. Эти два популярные на сегодняшний день слова » IT и Мультимедиа
Эта статья адресована для всех тех, кто хочет освежить в своей памяти или узнать, что означают эти два очень популярные на сегодняшний день в Интернете слова — HTML и HTTP. По возможности все написано максимально понятным языком. Также совсем чуть-чуть поговорим о связи между HTML и Мультимедиа.
Для начала HTTP и HTML — это разные вещи и желательно их не путать.
Что такое HTTP?
HTTP – это протокол по которому вы получаете web страницы с Интернета. На сегодняшний день этот протокол используется повсеместно. Например, когда вы хотите зайти на какой-то web-сайт, вы набираете в своем Интернет браузере адрес страницы. Также перед адресом вы можете указать протокол, по которому будет передана web-страница, например, http://. Это как раз и есть тот самый HTTP протокол. Также бывает https://, что означает безопасное соединение. Т.е. вся информация будет передаваться в зашифрованном виде. ОК, теперь разберем, что означает слово протокол. Предлагаю простой вариант определения, постарался убрать все лишнее.
Протокол передачи данных – набор соглашений и правил, обеспечивающий передачу информации между программным обеспечением и разнесённой в пространстве аппаратурой. Протоколов существует огромное множество. Например, электронную почту вы получаете по протоколу SMTP, когда используете почтовый клиент (Outlook, The Bat и др.).
Теперь, что такое HTML?
HTML – это язык разметки, с помощью которого создается большинство веб-страниц в Интернете. Язык HTML обрабатывается вашим браузером и отображается в виде web-страницы, т.е. в удобном для восприятия формате.
Давайте создадим что-нибудь простенькое с использованием языка HTML.
- Сначала создадим файл, например hello.html . Расширение html, как раз означает, что данный файл будет содержать язык разметки HTML.
- Поместим в этот файл следующие строчки языка HTML:
<html>
<head>
</head>
<body>
Привет! 🙂
</body>
</html>
Теперь я помещаю этот файл на свой web-сервер. Web-сервер – это программа, установленная на сервере, которая обрабатывает ваши запросы и выдает запрашиваемые web-страницы и не только.
Далее вы можете запросить эту HTML страничку, в вашем браузере, по адресу http://itmultimedia.ru/hello.html . Вы должны увидеть сообщение – “Привет! :)”. Получается, вы получили HTML страницу по протоколу HTTP.
HTML и Мультимедиа.
Вначале я обещал рассказать немного о связи HTML и мультимедиа. Связь действительно есть и она заключается в том, что вы можете помещать различные мультимедийные приложения, например видео плеер на вашу web-страничку. Для встраивания мультимедийных элементов, как раз можно использовать HTML. В дальнейшем я расскажу более подробно, какие мультимедийные элементы существуют и каким образом их лучше встраивать.
Также на сегодняшний день, сайты и блоги вы можете создавать без каких либо знаний о HTML разметке и др. Так как, существуют специальные Интернет сервисы, на которых вы можете быстро создать свои страницы с использованием дружественного и понятного взаимодействия с Интернет сервисом (например в социальной сети vkontakte или facebook). Но в любом случае, понимание того, что означает HTML и HTTP всегда может вам пригодиться. Если у вас появилось желание создать свою простенькую страницу на HTML, в Интернете вы сможете найти огромное количество информации об этом.
Приглашаю всех подписаться на новости моей публичной страницы ВКонтакте, ее адрес http://vk.com/itmultimedia . Буду рад видеть Вас в своих подписчиках!
Всего хорошего!
Похожие статьи
Что такое HTTP протокол: определение и основные понятия, связанные с HTTP
Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Начнем знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. Протокол HTTP – это как правила движения на дороге, только правила дорожного движения соблюдает не все и не всегда. А вот если наши приложения не будут соблюдать протокол HTTP, то они не смогут работать в интернете.
Что такое HTTP протокол
В данной статье мы познакомимся с протоколом HTTP, поговорим о том, что собой представляет протокол HTTP, дадим определение HTTP протоколу, посмотрим какие задачи решаются при помощи HTTP протокола, а так же ознакомимся с общими принципами работы HTTP протокола без изучения сложных деталей.
HTTP протокол: определение и принципы работы
Содержание статьи:
HTTP (HyperText Transfer Protocol) – это протокол седьмого уровня модели OSI для передачи данных, в основе которого лежит архитектура взаимодействие клиент-сервер. Изначально
Протокол HTTP довольно строгий и требует от приложений (кстати, протокол HTTP позволяет идентифицировать приложения) как клиентский, так и серверных строго исполнения стандарта (можешь посмотреть все стандарты HTTP протокола). Приведем несколько примеров HTTP клиентов: веб-браузер, приложения на Android, iOS, Windows. Приведем несколько примеров серверов HTTP: Apache, IIS, nginx, lighthttpd и другие.
Типичные задачи HTTP протокола и передача данных по HTTP
Типичные задачи, которые решает HTTP протокол: протокол HTTP осуществляет доступ к веб-ресурсам и обмен данными между пользовательскими приложениями. По сути HTTP протокол обеспечивает работу интернета. Иногда HTTP протокол используется как транспорт для других протоколов (при помощи HTTP протокола передается информация для других протоколов): SOAP, XML-RPC и другие.
Передача данных по HTTP протоколу осуществляется через TCP/IP соединение (вы можете прочитать более подробно про HTTP соединение и обсуждение в HTTP). Машина, которая выступает в роли сервера использует восьмидесятый TCP порт или порт 8080. Клиентские приложения, которые используют HTTP протокол обычно настроены на использование 80-го порта для соединения с HTTP сервером.
HTTP протокол – это абстракция над протоколом IP, вы можете обращаться к адресу m.vk.com, vk.com, но фактически, на третьем уровне модели OSI, вы будете обращаться к одному и тому же узлу с одним адресом IP, но информацию вы будете получать разную.
HTTP протокол не имеет инструментов для шифрования данных при передаче (если интересно, то почитайте про безопасность в HTTP), но для него есть расширяющие протоколы: SSL и TLS. По сути SSL – это более ранняя версия TLS протокола. Но об этом мы поговорим в других публикациях.
Данная серия заметок и записей будет целиком и полностью посвящена HTTP протоколу, мы детально на простых примерах и простыми словами разберемся с HTTP протоколом от и до.
Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением ZametkiNaPolyah.ru!
Протокол передачи данных — Википедия
Материал из Википедии — свободной энциклопедии
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 15 апреля 2019; проверки требуют 6 правок. Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 15 апреля 2019; проверки требуют 6 правок. У этого термина существуют и другие значения, см. Протокол. Протокол передачи данных — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. Эти соглашения задают единообразный способ передачи сообщений и обработки ошибок при взаимодействии программного обеспечения разнесённой в пространстве аппаратуры, соединённой тем или иным интерфейсом.Стандартизированный протокол передачи данных также позволяет разрабатывать интерфейсы (уже на физическом уровне), не привязанные к конкретной аппаратной платформе и производителю (например, USB, Bluetooth).
Сигнальный протокол используется для управления соединением — например, установки, переадресации, разрыва связи. Примеры протоколов: RTSP, SIP. Для передачи данных используются такие протоколы как RTP.
Сетево́й протоко́л — набор правил и действий (очерёдности действий), позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами.
Разные протоколы зачастую описывают лишь разные стороны одного типа связи. Названия «протокол» и «стек протоколов» также указывают на программное обеспечение, которым реализуется протокол.
Новые протоколы для Интернета определяются IETF, а прочие протоколы — IEEE или ISO. ITU-T занимается телекоммуникационными протоколами и форматами.
Наиболее распространённой системой классификации сетевых протоколов является так называемая модель OSI, в соответствии с которой протоколы делятся на 7 уровней по своему назначению — от физического (формирование и распознавание электрических или других сигналов) до прикладного (интерфейс программирования приложений для передачи информации приложениями).
Сетевые протоколы предписывают правила работы компьютерам, которые подключены к сети. Они строятся по многоуровневому принципу. Протокол некоторого уровня определяет одно из технических правил связи. В настоящее время для сетевых протоколов используется модель OSI (Open System Interconnection — взаимодействие открытых систем, ВОС).
Модель OSI — 7-уровневая логическая модель работы сети. Реализуется группой протоколов и правил связи, организованных в несколько уровней:
- на физическом уровне определяются физические (механические, электрические, оптические) характеристики линий связи;
- на канальном уровне определяются правила использования физического уровня узлами сети;
- сетевой уровень отвечает за адресацию и доставку сообщений;
- транспортный уровень контролирует очередность прохождения компонентов сообщения;
- сеансовый уровень координирует связь между двумя прикладными программами, работающими на разных рабочих станциях;
- уровень представления служит для преобразования данных из внутреннего формата компьютера в формат передачи;
- Уровни, интерфейсы и протоколы модели OSIприкладной уровень является пограничным между прикладной программой и другими уровнями, обеспечивая удобный интерфейс связи для сетевых программ пользователя.
В общей классификации протоколы делятся на низкоуровневые, протоколы верхнего уровня и протоколы промежуточного уровня. К промежуточному уровню относятся коммуникационные и протоколы аутентификации. Протоколами верхнего уровня являются прикладные, сеансовые протоколы и протоколы представления. Физический, канальный, сетевой и транспортный протоколы относят к низкоуровневым протоколам.[1]
Другая модель — стек протоколов TCP/IP — содержит 4 уровня:
- канальный уровень (link layer),
- сетевой уровень (Internet layer),
- транспортный уровень (transport layer),
- Передача по сети типового сообщенияприкладной уровень (application layer).
TCP/IP — набор протоколов передачи данных, получивший название от двух принадлежащих ему протоколов: TCP (англ. Transmission Control Protocol) и IP (англ. Internet Protocol)[2]
Наиболее известные протоколы, используемые в сети Интернет:
- HTTP (Hyper Text Transfer Protocol) — это протокол передачи гипертекста. Протокол HTTP используется при пересылке Web-страниц между компьютерами, подключенными к одной сети.
- FTP (File Transfer Protocol) — это протокол передачи файлов со специального файлового сервера на компьютер пользователя. FTP дает возможность абоненту обмениваться двоичными и текстовыми файлами с любым компьютером сети. Установив связь с удаленным компьютером, пользователь может скопировать файл с удаленного компьютера на свой или скопировать файл со своего компьютера на удаленный.
- POP3 (Post Office Protocol) — это стандартный протокол почтового соединения. Серверы POP обрабатывают входящую почту, а протокол POP предназначен для обработки запросов на получение почты от клиентских почтовых программ.
- SMTP (Simple Mail Transfer Protocol) — протокол, который задает набор правил для передачи почты. Сервер SMTP возвращает либо подтверждение о приеме, либо сообщение об ошибке, либо запрашивает дополнительную информацию.
- TELNET — это протокол удаленного доступа. TELNET дает возможность абоненту работать на любой ЭВМ находящейся с ним в одной сети, как на своей собственной, то есть запускать программы, менять режим работы и так далее. На практике возможности ограничиваются тем уровнем доступа, который задан администратором удаленной машины.
Другие протоколы:
- DTN — протокол, предназначенный для сетей дальней космической связи IPN, которые используются NASA.
- ↑ Распределенные системы. Принципы и парадигмы / Э. Таненбаум, М. ван Стеен. — СПб.: Питер, 2003. — с. 83-93 — (Серия «Классика computer science»). ISBN 5-272-00053-6-
- ↑ Hunt, Craig. TCP/IP Network Administration. — 3rd Edition. — O’Reilly Media, Inc.. — ISBN 0596002971.
Стандарты HTTP протокола. Версии HTTP протокола и их особенности
Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. В данной записи мы познакомимся со стандартами HTTP протокола, где их искать и что дадут нам эти стандарты, рассматривая стандарты HTTP, мы невольно затронем историю развития протокола HTTP, а заодно и то, какие изменения вводились от версии к версии HTTP.
Стандарты HTTP протокола. История развития HTTP протокола. Версии HTTP протокола
Рассмотрим какие есть стандарты HTTP протокола, посмотрев стандарты HTTP протокола мы заодно познакомимся с историей развития HTTP. Стандарт HTTP – это основной документ, исходя из которого мы должны разрабатывать свои приложения, использующие HTTP протокол.
Стандарты HTTP, версии HTTP протокола
На данный момент есть четыре стандарта HTTP протокола:
- Стандарт HTTP/0.9 – версия протокола HTTP 0.9 была разработана в 1991 году в ЦЕРН Тимом Бернерсом-Ли. Тим разработал HTTP протокол для облегчения доступа и создания навигации при помощи гипертекста. Протокол версии 0.9 был призван упорядочить взаимодействие между клиентом и сервером в сети. После появления стандарта HTTP/0.9 появилось разделение функций между клиентом и сервером при их взаимодействии. Стандарт HTTP/0.9 содержит в себе основы синтаксиса и семантики протокола HTTP.
- В 1996 году был выпущен информационный документ RFC 1945 (стандарт HTTP/1.0). Данный документ стал основой для реализации приложений и компонентов с использованием протокола HTTP версии 1.0. Кстати, разработчики могут идентифицировать свои приложения при передаче HTTP сообщений.
- В 1997 году была выпущена версия протокола HTTP1: был разработан стандарт HTTP/1.1 и описан он в документе RFC 2068. В 1999 году был доработан стандарт HTTP/1.1 (именно стандарт HTTP/1.1). Доработки коснулись: общего дизайна стандарта, формулировки и разъяснения некоторых терминов, исправлены опечатки, даны некоторые разъяснения по взаимодействию клиента и HTTP сервера в спорных ситуациях. Основным нововведением в версию протокола HTTP 1.1 был режим постоянного соединения (можете почитать про постоянные HTTP соединения), другими словами: за одно соединение можно было отправлять несколько HTTP запросов и получать несколько HTTP ответов в том порядке, в котором делались запросы. Вторым основным нововведение в версию протокола HTTP 1.1 является то, что теперь клиент при установке соединения с сервером должен обязательно посылать имя хоста в специальном поле HTTP заголовка (данное нововведение привело к массовому распространению виртуальных хостингов). На данный момент большинство приложений для своей работы используют HTTP протокол версии 1.1. Стоит заметить, что версия HTTP протокола является очень важным HTTP параметром, который должны использовать все приложения. Так же замечу, что независимо от номера стандарта HTTP протокол предъявляет требования к приложениям, которые его используют.
- 2015 году была опубликована финальная версия черновика протокола HTTP 2, это еще не стандарт, но черновик нам «показывает» куда будет двигаться развитие интернета. Версия протокола HTTP 2 является бинарной. В версии протокола HTTP 2 будет поддерживаться мультиплексирование (объединение) запросов, поскольку появится объединение, появится и приоритет запросов и многое другое, думаю, в завершении цикла заметок по HTTP мы познакомимся со всеми нововведениями HTTP.
Хочу обратить ваше внимание на то, что все документы RFC, которые я перечислил являются открытыми и ознакомиться c версиями протокола HTTP вы можете на языке Шекспира. Другими словами, найти стандарт HTTP не проблема. Добавим, что HTTP протокол относится к прикладному уровню всем известной модели сетевого взаимодействия OSI.
Не забывайте делиться своим мнением в комментариях и оставлять отзывы, это поможет сделать нашу работу лучше, с уважением ZametkiNaPolyah.ru!
Лекция 4. Протокол HTTP | Веб-программирование
Презентация
HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) — символьно-ориентированный клиент-серверный протокол прикладного уровня без сохранения состояния, используемый сервисом World Wide Web.
Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier – уникальный идентификатор ресурса) в запросе клиента. Основными ресурсами являются хранящиеся на сервере файлы, но ими могут быть и другие логические (напр. каталог на сервере) или абстрактные объекты (напр. ISBN). Протокол HTTP позволяет указать способ представления (кодирования) одного и того же ресурса по различным параметрам: mime-типу, языку и т. д. Благодаря этой возможности клиент и веб-сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
Структура протокола
Структура протокола определяет, что каждое HTTP-сообщение состоит из трёх частей (рис. 1), которые передаются в следующем порядке:
- Стартовая строка (англ. Starting line) — определяет тип сообщения;
- Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения;
- Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.
Рис. 1. Структура протокола HTTP
(дамп пакета, полученный сниффером Wireshark)
Стартовая строка HTTP
Cтартовая строка является обязательным элементом, так как указывает на тип запроса/ответа, заголовки и тело сообщения могут отсутствовать.
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
Метод URI HTTP/Версия протокола
Пример запроса:
GET /web-programming/index.html HTTP/1.1
Стартовая строка ответа сервера имеет следующий формат:
HTTP/Версия КодСостояния [Пояснение]
Например, на предыдущий наш запрос клиентом данной страницы сервер ответил строкой:
HTTP/1.1 200 Ok
Методы протокола
Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами (Табл. 1). Названия метода чувствительны к регистру.
| Метод | Краткое описание |
|---|---|
| OPTIONS | Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён. Сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера. Для того чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1. Результат выполнения этого метода не кэшируется. |
| GET | Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»: GET /path/resource?param1=value1¶m2=value2 HTTP/1.1 Согласно стандарту HTTP, запросы типа GET считаются идемпотентными[4] — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET. Кроме обычного метода GET, различают ещё условный GET и частичный GET. Условные запросы GET содержат заголовки If-Modified-Since, If-Match, If-Range и подобные. Частичные GET содержат в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно. |
| HEAD | Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения. Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая. |
| POST | Применяется для передачи пользовательских данных заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы. В отличие от метода GET, метод POST не считается идемпотентным[4], то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария). При результатах выполнения 200 (Ok) и 204 (No Content) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location. Сообщение ответа сервера на выполнение метода POST не кэшируется. |
| PUT | Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-* передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented). Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствуют находящемуся по данному URI ресурсу. Сообщения ответов сервера на метод PUT не кэшируются. |
| PATCH | Аналогично PUT, но применяется только к фрагменту ресурса. |
| DELETE | Удаляет указанный ресурс. |
| TRACE | Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера добавляют или изменяют в запросе. |
| LINK | Устанавливает связь указанного ресурса с другими. |
| UNLINK | Убирает связь указанного ресурса с другими. |
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Наиболее востребованными являются методы GET и POST — на человеко-ориентированных ресурсах, POST — роботами поисковых машин и оффлайн-браузерами.
Прокси-сервер
Прокси — это транзитный сервер, перенаправляющий HTTP-трафик. Прокси-серверы используются для ускорения выполнения запросов путем кэширования веб-страниц. В локальной сети применяется как межсетевой экран и средство управления HTTP-трафиком (например, для блокирования доступа к некоторым ресурсам). В Интернете прокси часто используют для анонимизации запросов — в этом случае веб-сервер получает ip-адрес прокси-сервера, а не реального клиента. В современных браузерах можно задать целый список прокси-серверов и переключаться между ними по мере необходимости (обычно такая возможность доступна через расширения или плагины браузера).
Коды состояния
Код состояния информирует клиента о результатах выполнения запроса и определяет его дальнейшее поведение. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC.
Каждый код представляется целым трехзначным числом. Первая цифра указывает на класс состояния, последующие — порядковый номер состояния (рис 1.). За кодом ответа обычно следует краткое описание на английском языке.
Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
Применяемые в настоящее время классы кодов состояния и некоторые примеры ответов сервера приведены в табл. 2.
| Класс кодов | Краткое описание |
|---|---|
| 1xx Informational (Информационный) | В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту. Примеры ответов сервера: 100 Continue (Продолжать) 101 Switching Protocols (Переключение протоколов) 102 Processing (Идёт обработка) |
| 2xx Success (Успешно) | Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения. Примеры ответов сервера: 200 OK (Успешно). 201 Created (Создано) 202 Accepted (Принято) 204 No Content (Нет содержимого) 206 Partial Content (Частичное содержимое) |
| 3xx Redirection (Перенаправление) | Коды статуса класса 3xx сообщают клиенту, что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. «редирект»). Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производиться автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления. Примеры ответов сервера: 300 Multiple Choices (Множественный выбор) 301 Moved Permanently (Перемещено навсегда) 304 Not Modified (Не изменялось) |
| 4xx Client Error (Ошибка клиента) | Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя. Примеры ответов сервера: 401 Unauthorized (Неавторизован) 402 Payment Required (Требуется оплата) 403 Forbidden (Запрещено) 404 Not Found (Не найдено) 405 Method Not Allowed (Метод не поддерживается) 406 Not Acceptable (Не приемлемо) 407 Proxy Authentication Required (Требуется аутентификация прокси) |
| 5xx Server Error (Ошибка сервера) | Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю. Примеры ответов сервера: 500 Internal Server Error (Внутренняя ошибка сервера) 502 Bad Gateway (Плохой шлюз) 503 Service Unavailable (Сервис недоступен) 504 Gateway Timeout (Шлюз не отвечает) |
Заголовки HTTP
Заголовок HTTP (HTTP Header) — это строка в HTTP-сообщении, содержащая разделённую двоеточием пару вида «параметр-значение». Формат заголовка соответствует общему формату заголовков текстовых сетевых сообщений ARPA (RFC 822). Как правило, браузер и веб-сервер включают в сообщения более чем по одному заголовку. Заголовки должны отправляться раньше тела сообщения и отделяться от него хотя бы одной пустой строкой (CRLF).
Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). После названия сразу должен следовать символ двоеточия. Значение может содержать любые символы ASCII, кроме перевода строки (CR, код 10) и возврата каретки (LF, код 13).
Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов в названии и значении не имеет значения (если иное не предусмотрено форматом поля).
Пример заголовков ответа сервера:
Server: Apache/2.2.3 (CentOS) Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT Content-Type: text/html; charset=UTF-8 Accept-Ranges: bytes Date: Thu, 03 Mar 2011 04:04:36 GMT Content-Length: 2945 Age: 51 X-Cache: HIT from proxy.omgtu Via: 1.0 proxy.omgtu (squid/3.1.8) Connection: keep-alive 200 OK
Все HTTP-заголовки разделяются на четыре основных группы:
- General Headers (Основные заголовки) — должны включаться в любое сообщение клиента и сервера.
- Request Headers (Заголовки запроса) — используются только в запросах клиента.
- Response Headers (Заголовки ответа) — присутствуют только в ответах сервера.
- Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.
Сущности (entity, в переводах также встречается название «объект») — это полезная информация, передаваемая в запросе или ответе. Сущность состоит из метаинформации (заголовки) и непосредственно содержания (тело сообщения).
В отдельный класс заголовки сущности выделены, чтобы не путать их с заголовками запроса или заголовками ответа при передаче множественного содержимого (multipart/*). Заголовки запроса и ответа, как и основные заголовки, описывают всё сообщение в целом и размещаются только в начальном блоке заголовков, в то время как заголовки сущности характеризуют содержимое каждой части в отдельности, располагаясь непосредственно перед её телом.
В таблице 3 приведено краткое описание некоторых HTTP-заголовков.
| Заголовок | Группа | Краткое описание |
|---|---|---|
| Allow | Entity | Список методов, применимых к запрашиваемому ресурсу. |
| Content-Encoding | Entity | Применяется при необходимости перекодировки содержимого (например, gzip/deflated). |
| Content-Language | Entity | Локализация содержимого (язык(и)) |
| Content-Length | Entity | Размер тела сообщения (в октетах) |
| Content-Range | Entity | Диапазон (используется для поддержания многопоточной загрузки или дозагрузки) |
| Content-Type | Entity | Указывает тип содержимого (mime-type, например text/html).Часто включает указание на таблицу символов локали (charset) |
| Expires | Entity | Дата/время, после которой ресурс считается устаревшим. Используется прокси-серверами |
| Last-Modified | Entity | Дата/время последней модификации сущности |
| Cache-Control | General | Определяет директивы управления механизмами кэширования. Для прокси-серверов. |
| Connection | General | Задает параметры, требуемые для конкретного соединения. |
| Date | General | Дата и время формирования сообщения |
| Pragma | General | Используется для специальных указаний, которые могут (опционально) применяется к любому получателю по всей цепочке запросов/ответов (например, pragma: no-cache). |
| Transfer-Encoding | General | Задает тип преобразования, применимого к телу сообщения. В отличие от Content-Encoding этот заголовок распространяется на все сообщение, а не только на сущность. |
| Via | General | Используется шлюзами и прокси для отображения промежуточных протоколов и узлов между клиентом и веб-сервером. |
| Warning | General | Дополнительная информация о текущем статусе, которая не может быть представлена в сообщении. |
| Accept | Request | Определяет применимые типы данных, ожидаемых в ответе. |
| Accept-Charset | Request | Определяет кодировку символов (charset) для данных, ожидаемых в ответе. |
| Accept-Encoding | Request | Определяет применимые форматы кодирования/декодирования содержимого (напр, gzip) |
| Accept-Language | Request | Применимые языки. Используется для согласования передачи. |
| Authorization | Request | Учетные данные клиента, запрашивающего ресурс. |
| From | Request | Электронный адрес отправителя |
| Host | Request | Имя/сетевой адрес [и порт] сервера. Если порт не указан, используется 80. |
| If-Modified-Since | Request | Используется для выполнения условных методов (Если-Изменился…). Если запрашиваемый ресурс изменился, то он передается с сервера, иначе — из кэша. |
| Max-Forwards | Request | Представляет механиз ограничения количества шлюзов и прокси при использовании методов TRACE и OPTIONS. |
| Proxy-Authorization | Request | Используется при запросах, проходящих через прокси, требующие авторизации |
| Referer | Request | Адрес, с которого выполняется запрос. Этот заголовок отсутствует, если переход выполняется из адресной строки или, например, по ссылке из js-скрипта. |
| User-Agent | Request | Информация о пользовательском агенте (клиенте) |
| Location | Response | Адрес перенаправления |
| Proxy-Authenticate | Response | Сообщение о статусе с кодом 407. |
| Server | Response | Информация о программном обеспечении сервера, отвечающего на запрос (это может быть как веб- так и прокси-сервер). |
В листинге 1 приведен фрагмент дампа заголовков при подключении к серверу http://example.org
http://www.example.org/ GET http://www.example.org/ HTTP/1.1 Host: www.example.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive HTTP/1.0 302 Moved Temporarily Date: Thu, 03 Mar 2011 06:48:28 GMT Location: http://www.iana.org/domains/example/ Server: BigIP Content-Length: 0 X-Cache: MISS from proxy.omgtu Via: 1.0 proxy.omgtu (squid/3.1.8) Connection: keep-alive ---------------------------------------------------------- http://www.iana.org/domains/example/ GET http://www.iana.org/domains/example/ HTTP/1.1 Host: www.iana.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.2.13) Gecko/20101203 SUSE/3.6.13-0.2.1 Firefox/3.6.13 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Proxy-Connection: keep-alive HTTP/1.0 200 OK Server: Apache/2.2.3 (CentOS) Last-Modified: Wed, 09 Feb 2011 17:13:15 GMT Content-Type: text/html; charset=UTF-8 Accept-Ranges: bytes Date: Thu, 03 Mar 2011 04:04:36 GMT Content-Length: 2945 Age: 9858 X-Cache: HIT from proxy.omgtu Via: 1.0 proxy.omgtu (squid/3.1.8) Connection: keep-alive ....
Несколько полезных примеров php-скриптов, обрабатывающих HTTP-заголовки, приведены в статье «Использование файла .htaccess» (редирект, отправка кода ошибки, установка last-modified и т.п.).
Тело сообщения
Тело HTTP сообщения (message-body), если оно присутствует, используется для передачи сущности, связанной с запросом или ответом. Тело сообщения (message-body) отличается от тела сущности (entity-body) только в том случае, когда при передаче применяется кодирование, указанное в заголовке Transfer-Encoding. В остальных случаях тело сообщения идентично телу сущности.
Заголовок Transfer-Encoding должен отправляться для указания любого кодирования передачи, примененного приложением в целях гарантирования безопасной и правильной передачи сообщения. Transfer-Encoding — это свойство сообщения, а не сущности, и оно может быть добавлено или удалено любым приложением в цепочке запросов/ответов.
Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения (message-body) может быть добавлено в запрос только когда метод запроса допускает тело объекта (entity-body).
Все ответы содержат тело сообщения, возможно нулевой длины, кроме ответов на запрос методом HEAD и ответов с кодами статуса 1xx (Информационные), 204 (Нет содержимого, No Content), и 304 (Не модифицирован, Not Modified).
Контрольные вопросы
- В каком случае клиент получит от сервера ответ с кодом 418?
Анатольев А.Г., 15.06.2016
Постоянный адрес этой страницы:
Что такое HTTP протокол. Зачем нужен Http протокол, и где он задействуется.
HTTP протокол для Web-страниц — то же, что FTP для файлового доступа.
Это — основной протокол World Wide Web. Каждый щелчок на Web-странице, каждая отображаемая на вашем экране картинка, каждое запрошенное стилевое оформление используют HTTP.
He будет преувеличением сказать, что HTTP — это костяк Web. Хотя большинство пользователей об этом и не задумываются, они «применяют» HTTP больше, чем любой другой протокол Internet.
Цитата из википедии:
HTTP (сокр. от английского HyperText Transfer Prоtocоl — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных . Основой HTTP протокола является Технология «клиент-сервер», то есть предполагается наличие потребителей (клиентов, пользователей), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения клиентов для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной веб-паутине для получения информации с веб-сайтов.
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
Как большая часть Internet, HTTP — это протокол, основанный на ASCII-коде, который четко описан и прост в использовании.
Хотя РНР в значительной мере защищает вас от деталей HTTP, понимание этого протокола — важная часть вашей квалификации как разработчика.
После того, как вы овладеете HTTP, вы будете лучше подготовлены к построению Web-приложений, поскольку будете понимать то, что происходит «за кулисами«.
Рекомендую ознакомиться:
Новый htc sensation xe обзор.
HTML/URL-протоколы обмена данными
/html/common-values/url/protocol:> Протоколы обмена данными_Схемы и протоколы
- bitcoin:
- Протокол криптовалюты Биткоин.
- data:
- Схема позволяющая включать небольшие элементы данных в URL строку.
- ed2k://
- Протокол файлообменной сети eDonkey.
- file://
- Ссылка на локальные файлы.
- ftp://
- Протокол передачи файлов. Ссылка на ftp-сайт или расположенный в нём документ.
- gopher://
- (от англ. «gopher» ‒ «суслик») протокол распределённого поиска и передачи документов (вытеснен HTTP протоколом).
- http://
- Протокол передачи произвольных данных.
- https://
- (от англ. «HyperText Transfer Protocol Secure» ‒ «Шифруемый Протокол Передачи ГиперТекста») стандартный HTTP протокол использующий шифрование (как правило, SSL или TLS).
- irc://
- (от англ. «Internet Relay Chat» ‒ «Ретранслирующий Интернет Чат») протокол прикладного уровня для обмена сообщениями в режиме реального времени.
- mailserver
- Доступ к данным с почтовых серверов.
- mailto:
- Указывает адрес электронной почты. При активации такой ссылки браузер запускает почтовый клиент для написания письма по указанному в ссылке адресу.
- market://
- Протокол Android Маркета.
- news:
- Новости Usenet.
- nfs
- Имя файла в сетевой файловой системе NFS.
- nntp://
- Новости Usenet через протокол NNTP.
- prospero
- Служба каталогов Prospero Directory Service.
- rtmp://
- (от англ. «Real Time Messaging Protocol» ‒ «Протокол обмена Сообщениями в режиме Реального Времени») проприетарный протокол потоковой передачи данных (используется для передачи через интернет потокового видео и аудиопотоков с веб-камер).
- rtsp://
- (от англ. «Real Time Streaming Protocol» ‒ «Потоковый Протокол Реального Времени») Потоковый протокол реального времени (позволяет клиенту удалённо управлять потоком мультимедиа данных с сервера).
- skype:
- Указывает название учетной записи или телефонный номер. При активации такой ссылки браузер запускает Skype для осуществления звонка указанному в ссылке абоненту или по указанному номеру.
- sms:
- Открытие редактора SMS (работает только в некоторых мобильных телефонах).
- smsto:
- Открытие редактора SMS (работает только в некоторых мобильных телефонах).
- steam://
- Протокол Steam.
- tel:
- Указывает телефонный номер. При активации такой ссылки браузер запускает программу осуществляющую телефонные звонки.
- telnet://
- Ссылка на интерактивную сессию Telnet.
- wais://
- (от англ. «Wide Area Information Servers» ‒ «Широкие Области Информационных Серверов») ссылка на базу данных системы WAIS.
- xmpp://
- (от англ. «Extensible Messaging and Presence Protocol» ‒ «расширяемый Протокол Обмена Сообщениями и информацией о Присутствии») открытый, основанный на XML, свободный для использования протокол для мгновенного обмена сообщениями и информацией о присутствии.
Схемы браузеров
- about:
- Служебные страницы некоторых браузеров (Chrome, Firefox, Opera, Maxthon).
- chrome://
- Служебные страницы браузера Google Chrome или браузеров использующих движок Gecko.
- opera://
- Служебные страницы браузера Opera.
- view-source:
- Просмотр исходного кода указанной web-страницы (указывается вместе с протоколом страницы.
Псевдопротокол
- javascript:
- Выполняет скрипт указанный после псевдопротокола.