вторник, 2 февраля 2016 г.

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

Информация, которая не является частью стандарта HTTP/1.0

Internet media type "message/http"


Помимо определения протокола HTTP/1.0 это документ служит в качестве спецификации для Internet media type "message/http" (Зарегистрирован IANA).

Media Type name:         message
Media subtype name:      http
Required parameters:     none
Optional parameters:     version, msgtype
       version: The HTTP-Version number of the enclosed message
                (e.g., "1.0"). If not present, the version can be
                determined from the first line of the body.
       msgtype: The message type -- "request" or "response". If
                not present, the type can be determined from the
                first line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are permitted
Security considerations: none

Отличия от RFC 1521


HTTP/1.0 использует много конструкций из Internet Mail (RFC 822) и MIME, чтобы позволить передать Entity-s в открытых различных представлениях и с расширяемыми механизмами.

RFC 1521 требует, чтобы содержимое с Content-Type "text" использует для обозначения конца строки CRLF, и запрещает использование CR и LF, кроме как для данного случая. HTTP же разрешает и CRLF, и CR и LF. Поэтому перед доставкой от HTTP к RFC 1521, там где это возможно, необходимо CR и LF преобразовывать как CRLF.

RFC 1521 не использует Content-Encoding. Прокси и шлюзы от HTTP до MIME-подобных протоколов, должны либо изменять значение Content-Encoding, либо декодировать Entity-Body перед дальнейшей отправкой сообщения.

HTTP не использует Content-Transfer-Encoding (CTE) из RFC 1521. Прокси и шлюзы от MIME-подобных протоколов к HTTP должны удалять не тождественные CTE кодировки, перед тем как доставить сообщение HTTP клиенту.

В отличие от RFC 1521 в multipart body-part можно указывать любые необходимые HTTP-заголовки, а не только те, которые начинаются с Content-*.


Дополнительные методы запросов


PUT - создать или обновить Entity по заданному Request-URI. Различие между PUT и POST заключается в том, что Request-URI в POST - адрес обработчика Entity, а в PUT - идентифицирует адрес Entity, расположенной в запросе.

DELETE - удалить ресурс по Request-URI.

LINK - "связать" ресурс Request-URI с другим.

UNLINK - удалить связи Link, с ресурсом Request-URI.


Дополнительные заголовки


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


MIME-Version - версия MIME протокола (RFC 1521)

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


Accept - список медиа дипазонов, которые принимаются в качестве ответа (пример "text/*")
Accept-Charset - в какой кодировке предпочтительно отдавать ответ (по умолчанию кодировки US-ASCII и ISO-8859-1)
Accept-Encoding - наподобие Accept, но только относительно содержимого ответа.
Accept-Language - наподобие Accept, но только тут речь о предпочтительных естественных языках в ответе.

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


Retry-After - может использоваться с ответом 503, показывающий как долго сервис ожидается быть недоступным, значение - HTTP-дата или количество секунд с момента запроса.

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


Content-Language - естественный язык содержимого.
Link - на кого ссылается данный ресурс (Link может использоваться более одного раза)
Title - заголовок Entity.
URI - URI, по которому можно получить доступ к ресурсу (хотя не факт)

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

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