понедельник, 1 февраля 2016 г.

RFC 1945 - Hypertext Transfer Protocol (конспект)


HTTP - объектно ориентированный протокол уровня приложений, без запоминания состояния.

HTTP использует "[major].[minor]" (версии). Минорные версии не изменяют структуру сообщения, а мажорные да. Этот документ определяет версии 0.9 и 1.0.

Соединения (клиент) - Запрос - Ответ - Закрытие (сервером)

   запрос ------------------>
UA --------------v-----------O
   <------------------- ответ
 
   запрос ----------------------------->
UA ---v--- A ---v--- B ---v--- C ---v--- O
   <------------------------------ ответ
 
   запрос ---------> (кеширование ответа от C)
UA ---v--- A ---v--- B - - - C - - - O
   <---------- ответ

Запрос


Simple-Request = "GET" SP Request-URI CRLF
Full-Request = Request-Line *( Заголовки Общие | Запроса | Сущности ) CRLF [ Entity-Body ]

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Различие между Simple-Request и Request-Line в Full-Request в присутствии HTTP-Version и
доступности методов помимо GET.

Uniform Resource Identifie - Request-URI. Абсолютный запрос разрешен, когда он выполнен к прокси, в противном случае используется относительный. Путь кодируется в виде "% HEX HEX" по RFC 1738, а затем декодируется получателем.


Ответ


Full-Response = Status-Line *( Заголовки Общие | Ответа | Сущности ) CRLF [ Entity-Body ]
Simple-Response = [ Entity-Body ]

Первая линия Full-Response - это Status-Line. Присутствие этой строки различает Full-Response от Simple-Response. Наличие этой строки в начале ответа в Simple-Response может смутить клиента.


Методы


Чувствительны к регистру.

GET
Получить информацию в форме сущности идентифицированной по Request-URI.
Если же есть заголовк If-Modified-Since, то сущность передаётся только в том случае,
когда удовлетворяет данному условию, иначе возвратиться Not modified.

HEAD
Получить лишь заголовки без сущности.

POST
Взаимодействие с сервером. 400 (Bad request) если нельзя определить Content-Length. Кэшировать не нужно.


Заголовки


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

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

Общие заголовки


  • Date отображает дату, когда сообщение был сгенерировано.
  • Pragma применяется для всех запросов/ответов. (Pragma: no-cache)

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


  • Authorization используется для авторизации и содержит тип авторизиии и закодированную в Base64 строку вида "user_id:password". (Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==)
  • From содержит емайл того, кто послал запрос.
  • If-Modified-Since используется с GET и делает его запросом с условием. Если ресурс не был изменён, то в ответе придёт 304 (not modified) безо всякого Entity-Body.
  • Referer содержит информацию откуда пришёл клиент (если относительный адрес, то значит с того же домена).
  • User-Agent содержит информацию о пользовательском UA.

Заголовки ответа


  • Location содержит расположение ресурса. Для запросов 3xx должен содержать адрес для переадресации.
  • Server информация о сервере.
  • WWW-Authenticate ответ на неавторизованный запрос, который содержит тип аутентификации и название защищённой зоны.

Заголовки сущности


  • Allow (игнорируется в POST запросах) - список доступных методов. Allow: GET, HEAD
  • Content-Encoding модификатор для медиа-типа, говорит о том, что была применена кодировка. (Content-Encoding: x-gzip)
  • Content-Length размер сообщения в байтах
  • Content-Type медиа тип сообщения
  • Expires содержит дату, после которой entity следует считать устаревшим.
  • Last-Modified дата последней модификации ресурса. Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Коды статусов ответа


Коды могут быть расширены, неизвестный код определять по первой цифре, а Entity объяснит причину. Вместе с кодом так же передаётся пояснение к нему (прим. 204 no content)

1xx, 204 (no content), 304 (not modified) - не должны возвращать Entity-Body;
все остальные ответы должны возвращать Content-Lenght (0) или Entity-Body.

Информационные (1xx) - не используются в HTTP/1.0


Успешные (2xx) - запрос получили, поняли и приняли

  • 200 - OK GET - entity, соответствующее запрошенному ресурсу посылается в ответе. HEAD - содержит только заголовки, без Entity. POST - entity, описывающий или содержащий результат действия.
  • 201 - Created Ресурс создан. Ссылка на него в Entity-части. (Только POST может создавать ресурсы)
  • 202 - Accepted Запрос принят для обработки, но обработка еще не завершена.
  • 204 - No content Запрос выполнен, но в ответе нечего показать.

Переадресация (3xx)

Более 5-и раз переадресации обычно обозначает бесконечную петлю.

  • 300 - Multiple Choices Напрямую не используется HTTP/1.0 приложениями. Запрошенный ресурс доступен в более чем одном местоположении. Информации о них в Entity. Для выделенного ресурса в Location.
  • 301 Moved Permanently Ресурс перемещен постоянно в новую локацию Location. (Если был POST запрос то автоматически переадресацию делать не нужно).
  • 302 Moved Temporarily Временно изменён адрес ресурса (в Location) (Если был POST запрос то автоматически переадресацию делать не нужно)
  • 304 Not Modified Если был GET запрос с If-Modified-Since заголовком.

Ошибки клиента (4xx)

Перед закрытием соединения сервер должен получить подтверждение о получении клиентом ответа. Если же клиент продолжает посылать запросы, то сервер пошлёт "reset packet" клиенту, который может очистить неподтверждённые клиентские входные буфферы.

  • 400 Bad Request Непонятный синтаксис запроса или т.п.
  • 401 Unauthorized Необходима авторизация, либо авторизация отклонена.
  • 403 Forbidden Сервер понял запрос, но отказался выполнять.
  • 404 Not Found Запрошенный ресурс не найден.

Ошибки сервера (5xx)

  • 500 Internal Server Error Сервер не смог выполнить запрос.
  • 501 Not Implemented Не поддерживаемая функциональность (например метод запроса PUT)
  • 502 Bad Gateway Сервер, действовавший как шлюз или прокси встретил ошибку со стороны следующего сервера в цепи, при попытке выполненить запрос.
  • 503 Service Unavailable Сервер временно недоступен.


Конструкции


Дата/время
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format (использовать не нужно)

Тип (type/subtype)
Вычисляется в таком порядке: 1) По Content-Type. 2) По содержимому и расширению. 3) "application/octet-stream" - иначе.

Множественные типы (multipart types)
Позволяют размещать несколько сущностей в одном сообщении Entity. Включают boundary параметр. Разделяются части с помощью CRLF. Каждая часть может содержать значимые для неё заголовки.

Длина
Вычисляется в таком порядке: 1) По Content-Length. 2) Или вычисляется по закрытию соединения.

Конструкции MIME
Смотреть в RFC 1521

Цитирование
Цитирование с помощью двойных кавычек "", одиночное с помощь обратного слеша не поддерживается.

http_URL
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
для не TCP соединений необходим использовать другие схемы.

Кодирование сообщения
content-coding = "x-gzip" ("gzip") | "x-compress" ("compress") | token

Набор символов
"ISO-8859-1" - charset по умолчанию, если явно не указан.

Идентификаторы
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4


Авторизация


401 (unauthorized) - как приглашение для авторизации
403 (forbidden) - если не желает авторизовывать

Базовая аутентификация
Сервер авторизует запрос, если проверит user-ID, password для защищенной зоны (Request-URI)

Прокси не должны изменять WWW-Authenticate, Authorization заголовки и не должны кешировать ответы на запросы с Authentication заголовком.

Ответ 401 на неавторизованный запрос (WallyWorld - название защищенной зоны)
WWW-Authenticate: Basic realm="WallyWorld" (заголовок ответа)

Запрос для авторизации (encode_base64($user .":". $pass))
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== (заголовок запроса)


Безопасность и частная жизнь


Basic схема авторизации не безопасна. В то же время HTTP/1.0 не запрещает дополнительные средства авторизации и шифрования.

Безопасные методы: GET, HEAD - они лишь для получения информации.

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

Передача чувствительной информации Server, Referer, From - необходимо позволить настраивать.

И следите за '..' в путях.

Комментариев нет:

Отправить комментарий