Информация, которая не является частью стандарта HTTP/1.0
Помимо определения протокола HTTP/1.0 это документ служит в качестве спецификации для Internet media type "message/http" (Зарегистрирован IANA).
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, по которому можно получить доступ к ресурсу (хотя не факт)
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, по которому можно получить доступ к ресурсу (хотя не факт)
Комментариев нет:
Отправить комментарий