Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

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

GET /index.html HTTP/1.0
Host: www.example.com
User-Agent: Mozilla/4.05 (WinNT; 1)


НТТР/1.0 200 OK
Content-type: text/plain
Date: Fri, 10 Jan 1998 08:17:58 GMT
Server: Apache/1.2.6
Last-modified: Mon, 12 Jun 1997 21:53:08 GMT
Content-length: 14

Hello, world!

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию - 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

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

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера - строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

100-199 Информационный
200-299 Запрос клиента успешен
300-399 Запрос клиента переадресован, необходимы дальнейшие действия
400-499 Запрос клиента является неполным
500-599 Ошибки сервера

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

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод - это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

LINK Связывает информацию заголовка с документом на сервере. 
UNLINK Отменяет связь информации заголовка с документом на сервере. 
PUT Помещает тело содержимого запроса по указанному URI. 
DELETE Удаляет данные, находящиеся на сервере по заданному URI. 
OPTIONS Запрашивает информацию о коммуникационных параметрах сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса следует использовать символ *.
TRACE Требует, чтобы тело содержимого запроса было возвращено без изменений. Используется для отладки.

Метод GET

GET - это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком '/', а затем, после символа '&' - именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом '&'. Например:

GET /journal/search?month=august&date=24 HTTP/1.О

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

GET /cgi-bin/display.pl/text/doc.txt

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

POST /cgi-bin/birthday.pl HTTP/1.0
User-Agent; Mozilla/4.05 (WinNT; 1)
Host: www.ora.com
Content-type: application/x-www-form-urlencoded
Content-Length: 20

nionth=august&date=24

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

• время изменения документа;
• размер документа;
• тип документа;
• тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

WWW-Authenticate: Basic realm="WallyWorld

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия ":". Строка авторизации кодируется в base64.

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ##

В реальной жизни используется тип авторизации Basic и NTLM.

Заголовки запроса

В запросе клиент должен передать URI запрашиваемого документа. Это может быть сделано в абсолютной или относительной форме. В первом случае в состав URI должны входить название протокола и имя сервера.

GET http://www.ru/index.html HTTP/1.0

Во втором случае передается только путь к документу.

GET /index.htm HTTP/1.0

В этом случае имя и порт хоста, может быть передано в строке заголовка Host:

Host: www.example.com:8001

Наличие имени хоста необходимо для обращений к прокси-серверу, или для обращения к одному из виртуальных хостов размещенных на одном сервере. Если хост, заданный одним из двух способов, не существует, то сервер возвращает ответ 400- Bad Request.

Поля заголовка запроса позволяют клиенту передавать серверу дополнительную информацию о запросе и о самом клиенте.

User-Agent: - версия пользовательской программы
Accept-Language:
Accept-Charset: Указание на предпочтительный язык документа (если документ существует на нескольких языках) и предпочтительную кодировку для текстовых документов.
Accept-Encoding: Допустимые схемы сжатия передаваемой информации.
Range: Запрос части документа, например для реализации докачки файлов.
If-Modified-Since: Запрос кэшированного документа. Позволяет получать только изменившиеся документы.

Передача данных в ответе сервера

Несколько заголовков используемых в ответе сервера, позволяют точно описать формат и размер передаваемых данных.

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

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

GET / HTTP/1.0


HTTP/1.0 200 OK
Content-Type: text/html; charset=utf8

<html>
<body>
</body>
</html>

В типе сообщения для текстовых форматов может быть указана использованная кодировка.

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

Content-Encoding: gzip

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

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

Transfer-Encoding: chunked

А тело сообщения строится по следующим правилам

Длина куска (текстовое представление шестнадцатеричного числа)<CR><LF>
Тело куска<CR><LF>
...
0<CR><LF>

Признаком завершения передачи является кусок нулевой длины.

HTTP/1.1 200 OK
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Transfer-Encoding: chunked

4
aaaa
2
bb
0

Следует отметить, что символы в конце куска, не являются его частью. Подобное кодирование очень удобно в тех случаях, когда размер данных заранее неизвестен, и достаточно велик.

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES—

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

Успешные ответы

200 OK  Запрос клиента обработан успешно, и ответ сервера содержит затребованные данные. 

Переадресация

301 Moved Permanently   Затребованный URI перенесен на новое место (возможно на другой сайт). Новое местонахождение затребованного документа указывается в заголовке Location. 
302 Moved Temporarily   Затребованный URI перемешен, но лишь временно.
304 Not Modified    Проверка ого, что файл не менялся с запрошенной даты (заголовок lf-Modified-Since в запросе).

Логические ошибки

400 Bad Request Сервер обнаружил в запросе клиента синтаксическую ошибку. 
401 Unauthorized    Требуется пароль.
403 Forbidden       Доступ к документу запрещен
404 Not Found   Документ по указанному URI не существует. 
407 Proxy Authentication Required   Требуется пароль к proxy-серверу.

Ошибки сервера

500 Internal Server Error   При обработке запроса на один из компонентов сервера аварийно завершился. 
501 Not Implemented     Клиент запросил выполнение действия, которое сервер выполнить не может. 
504 Gateway Time-out    proxy-сервер не получил ответа от веб-сервера