rd_45.134-2000 (524304), страница 18

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 18)

Базовые определения:

OCTET ::=

CHAR ::=

UPALPHA ::=

LOALPHA ::=

ALPHA ::= UPALPHA | LOALPHA

DIGIT ::=

CTL ::= <любой управляющий символ US-ASCII

(октеты от 0 до 31) и DEL (127)>

CR ::=

LF ::=

SP ::=

HT ::=

::=

CRLF ::= CR LF

Заголовок HTTP может быть разбит на несколько строк. 2-я и далее строка заголовка должны начинаться с пробела или табуляции.

LWS ::= [CRLF] 1*( SP | HT )

Слова *TEXT могут содержать символы набора, отличного от ISO 8859-1[16] только в случае, если они закодированы в соответствии с RFC 2047[17].

TEXT ::=

HEX ::= "A" | "B" | "C" | "D" | "E" | "F"

| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

token ::= 1*

tspecials ::= "(" | ")" | "" | "@"

| "," | ";" | ":" | "\" |

| "/" | "[" | "]" | "?" | "="

| "{" | "}" | SP | HT

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

comment ::= "(" *( ctext | comment ) ")"

ctext ::=

Строка текста, заключенная в двойные кавычки ("строка в кавычках"), обрабатывается как единое слово.

quoted-string ::= ( *(qdtext) )

qdtext ::=

Конструкция квотирования "\" может использоваться только внутри "строки в кавычках" и комментария.

quoted-pair ::= "\" CHAR

5.2. Элементы протокола

5.2.1. Версия HTTP

Версия содержится в поле HTTP-Version в первой строке сообщения.

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Номер DIGIT не должен начинаться с нулей.

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

5.2.2. Универсальный идентификатор ресурса (URI)

5.2.2.1. Синтаксис

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

URI ::= ( absoluteURI | relativeURI ) [ "#" fragment ]

absoluteURI ::= scheme ":" *( uchar | reserved )

relativeURI ::= net_path | abs_path | rel_path

net_path ::= "//" net_loc [ abs_path ]

abs_path ::= "/" rel_path

rel_path ::= [ path ] [ ";" params ] [ "?" query ]

path ::= fsegment *( "/" segment )

fsegment ::= 1*pchar

segment ::= *pchar

params ::= param *( ";" param )

param ::= *( pchar | "/" )

scheme ::= 1*( ALPHA | DIGIT | "+" | "-" | "." )

net_loc ::= *( pchar | ";" | "?" )

query ::= *( uchar | reserved )

fragment ::= *( uchar | reserved )

pchar ::= uchar | ":" | "@" | "&" | "=" | "+"

uchar ::= unreserved | escape

unreserved ::= ALPHA | DIGIT | safe | extra | national

escape ::= "%" HEX HEX

reserved ::= ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"

extra ::= "!" | "*" | "'" | "(" | ")" | ","

safe ::= "$" | "-" | "_" | "."

unsafe ::= CTL | SP | | "#" | "%" | ""

national ::= <любой OCTET кроме ALPHA, DIGIT,

reserved, extra, safe, и unsafe>

Если длина URI превышает максимальную длину, обрабатываемую сервером, сервер должен выдать ответ статуса 414.

5.2.2.2. HTTP URL

URL - универсальный указатель расположения ресурса. URL - тип URI, со схемой http.

http_URL ::= "http:" "//" host [ ":" port ] [ abs_path ]

host ::= <Разрешенное имя домена Internet или адрес IP

в форме десятичных чисел, разделенных точками,

в соответствии с п. 2.1. RFC 1123 [18])

port ::= *DIGIT

Если port не указан, предполагается порт по умолчанию 80. Если в запросе не указан abs_path, вместо него должен присутствовать "/".

5.2.2.3. При сравнении двух URI с целью выяснения идентичности, клиент должен проводить пооктетное сравнение с учетом регистра всех символов URI. При этом:

- если порт не указан, он считается эквивалентным порту по умолчанию;

- при сравнении имен узлов регистр символов не должен учитываться;

- при сравнении схем регистр не должен учитываться;

- пустой абсолютный путь abs_path эквивалентен значению "/" abs_path.

Символы, не входящие в группы "reserved" и "unsafe" эквивалентны их коду, представленному как ""%" HEX HEX".

5.2.3. Формат даты и времени

5.2.3.1. Полная дата

Существует три допустимых формы представления даты/времени:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822 [2], с учетом изменений,

; внесенных RFC 1123 [18]

Sunday, 06-Nov-94 08:49:37 GMT ; RFC 1036 [19]

Sun Nov 6 08:49:37 1994 ; формат ANSI C asctime()

Время и дата, указанные в метках даты/времени, должны соответствовать Среднему Гринвичскому времени

HTTP-date ::= rfc1123-date | rfc850-date | asctime-date

; rfc850 - rfc850[20]

rfc1123-date ::= wkday "," SP date1 SP time SP "GMT"

rfc850-date ::= weekday "," SP date2 SP time SP "GMT"

asctime-date ::= wkday SP date3 SP time SP 4DIGIT

date1 ::= 2DIGIT SP month SP 4DIGIT

; день месяц год (Например, 02 Jun 1982)

date2 ::= 2DIGIT "-" month "-" 2DIGIT

; день-месяц-год (Например, 02-Jun-82)

date3 ::= month SP ( 2DIGIT | ( SP 1DIGIT ))

; месяц день (Например, Jun 2)

time ::= 2DIGIT ":" 2DIGIT ":" 2DIGIT

; 00:00:00 - 23:59:59

wkday ::= "Mon" | "Tue" | "Wed"

| "Thu" | "Fri" | "Sat" | "Sun"

weekday ::= "Monday" | "Tuesday" | "Wednesday"

| "Thursday" | "Friday" | "Saturday" | "Sunday"

month ::= "Jan" | "Feb" | "Mar" | "Apr"

| "May" | "Jun" | "Jul" | "Aug"

| "Sep" | "Oct" | "Nov" | "Dec"

5.2.3.2. Период в секундах

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

delta-seconds ::= 1*DIGIT

5.2.4. Наборы символов

Термин "набор символов" в протоколе HTTP аналогичен такому же термину, определенному в протоколе MIME.

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

charset ::= token

где значение token должно соответствовать RFC 1700 [9].

5.2.5. Кодирование содержимого

Значения способа кодирования содержимого указывают на преобразование кодировки (например, сжатие), которое применялось, либо может быть применено к сущности.

content-coding ::= token

Определены следующие значения token: gzip (GNU zip согласно RFC 1952 [21]) и compress.

5.2.6. Кодирование при передаче

Значения кодирования при передаче указывают на преобразование кодировки, которое применялось, либо может быть применено к телу сущности с целью обеспечения "безопасной транспортировки" по сети. Кодирование при передаче является свойством сообщения, а не сущности.

transfer-coding ::= "chunked" | transfer-extension

transfer-extension ::= token

Порционное кодирование (chunked encoding) изменяет тело сообщения таким образом, что оно передается как последовательность порций. Каждая порция имеет свой индикатор размера, за которым следует необязательный раздел, содержащий поля заголовка сущности. Таким образом кодирование при передаче позволяет передавать сообщения с динамически генерируемым содержимым.

Chunked-Body ::= *chunk

"0" CRLF

footer

CRLF

chunk ::= chunk-size [ chunk-ext ] CRLF

chunk-data CRLF

hex-no-zero ::=

chunk-size ::= hex-no-zero *HEX

chunk-ext ::= *( ";" chunk-ext-name [ "=" chunk-ext-value ] )

chunk-ext-name ::= token

chunk-ext-val ::= token | quoted-string

chunk-data ::= chunk-size(OCTET)

footer ::= *entity-header

5.2.7. Типы информации

Для обеспечения открытого определения и согласования типа информации используются поля заголовка Content-Type и Accept.

media-type ::= type "/" subtype *( ";" parameter )

type ::= token

subtype ::= token

parameter ::= attribute "=" value

attribute ::= token

value ::= token | quoted-string

Между элементами type и subtype, а также между parameter и value не должны использоваться символы LWS в качестве разделителя.

Значения media-type должны соответствовать RFC 2048 [15].

5.2.7.1. Канонические представления информации

Для каждого типа информации зарегистрирована каноническая форма представления. При пересылке в теле сообщения HTTP-информация должна быть представлена в канонической форме.

5.2.7.1.1. Тип text.

В качестве разделителя линии в теле сообщения при типе media-type text могут использоваться отдельные символы CR, LF и пара символов CRLF.

Если не указан набор символов, по умолчанию должен использоваться ISO-8859-1 [16].

5.2.7.2. Если сообщение содержит несколько тел с различными типами информации, все части сообщения должны иметь формат MIME. В отличие от MIME эпилог (epilogue) не должен передаваться.

5.2.8. Метки продуктов

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

product ::= token ["/" product-version]

product-version ::= token

Например:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Server: Apache/0.8.4

5.2.9. Параметр качества содержимого

Процедура согласования содержимого использует короткие числа с плавающей запятой для указания относительной важности (веса) различных параметров согласования. Веса приведены к нормализованной форме в диапазоне от 0 до 1, где 0 - минимальный вес, а 1 - максимальный. Вес не должен содержать более 3-х цифр после десятичной точки.

qvalue ::= ( "0" [ "." 0*3DIGIT ] )

| ( "1" [ "." 0*3("0") ] )

5.2.10. Теги языка

Теги языка указывают на естественный язык, используемый для передачи информации между людьми. Синтаксис и допустимое содержание тега языка должны соответствовать RFC 1766 [22].

language-tag ::= primary-tag *( "-" subtag )

primary-tag ::= 1*8ALPHA

subtag ::= 1*8ALPHA

Первый двухсимвольный тег primary-tag - это аббревиатура языка в соответствии с ISO 639 [23], а первый двухбуквенный subtag - это код страны по ISO 3166 [24].

5.2.11. Теги сущности

Теги сущности используются для сравнения двух или более сущностей, поступивших от одного запрашиваемого ресурса.

entity-tag ::= [ weak ] opaque-tag

weak ::= "W/"

opaque-tag ::= quoted-string

Теги сущности должны быть уникальны для всех версий всех сущностей, относящихся к отдельному ресурсу.

5.2.12. Блоки диапазонов

HTTP 1.1 позволяет клиенту затребовать, чтобы только часть (диапазон) сущности ответа была включена в ответ. Сущность может быть разбита на поддиапазоны в соответствии с различными структурными блоками.

range-unit ::= bytes-unit | other-range-unit

bytes-unit ::= "bytes"

other-range-unit ::= token

Единственным обязательным для реализации блоком является bytes-unit.

5.3. Сообщение HTTP

5.3.1. Типы сообщений

Сообщения разделяются на запросы клиента к серверу и ответы сервера клиенту.

HTTP-message ::= Request | Response

Запросы и ответы используют общий формат сообщений RFC 822 [2] для передачи сущностей (полезной нагрузки сообщения). Оба типа сообщения состоят из начальной строки, одной или более строк заголовка, пустой строки, указывающей на конец заголовка, и необязательного тела сообщения.

generic-message ::= start-line

*message-header

CRLF

[ message-body ]

start-line ::= Request-Line | Status-Line

Сервер должен игнорировать пустые строки, поступающие перед Request-Line.

5.3.2. Заголовки сообщений

Поля заголовка HTTP, включая поля общего заголовка, заголовка запроса, заголовка ответа и заголовка сущности, должны соответствовать формату п. 3.1. RFC 822 [2]. Поля заголовка могут занимать несколько строк, но строки, следующие за первой, должны начинаться с 1*(SP | HT).

message-header ::= field-name ":" [ field-value ] CRLF

field-name ::= token

field-value ::= *( field-content | LWS )

field-content ::= <октеты, составляющие значение поля и

состоящие либо из *TEXT, либо из комбинаций

token, tspecials и quoted-strings>

Порядок полей в заголовке не имеет значения. Но прокси не должен изменять порядок полей в перенаправляемом сообщении.

5.3.3. Тело сообщения

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

message-body ::= entity-body |

соответствии с Transfer-Encoding>

Ответы 1хх (информационные), 204 (нет содержимого) и 304 (не изменен) не должны содержать тело сообщения. Все остальные ответы должны содержать тело, хотя возможно и нулевой длины.

На наличие тела сообщения указывает присутствие полей Content-Length и Transfer-Encoding.

5.3.4. Длина сообщения

При включении тела сообщения в сообщение, длина (конец) этого тела сообщения определяется следующим образом:

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

2. Если присутствует поле заголовка Transfer-Encoding и указывает на применение порционного кодирования, то длина определяется порционным кодированием.

3. Если присутствует поле Content-Length, его значение определяет длину тела сообщения в байтах.

4. Если сообщение использует тип информации "multipart/byteranges", который является самоограничивающимся, то этот тип информации определяет длину тела сообщения. Этот тип информации должен использоваться сервером только тогда, когда в запросе присутствует заголовок Range с несколькими определителями byte-range, который показывает, что клиент может обработать ответ "multipart/byteranges".

5. Закрытием соединения (только для тела ответа).

Сообщения не должны содержать одновременно поле Content-Length и поля порционного кодирования. В случае получения подобного сообщения значение Content-Length должно игнорироваться.

5.3.5. Общие поля заголовка

Данные поля используются и в запросах, и в ответах и применяются к сообщению в целом, а не к передаваемым сущностям.

general-header ::= Cache-Control

| Connection

| Date

| Pragma

| Transfer-Encoding

| Upgrade

| Via

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

5.4. Запрос

Сообщение запроса содержит в первой строке сообщения метод, применяемый к ресурсу, идентификатор ресурса и версию используемого протокола.

Request ::= Request-Line

*( general-header

| request-header

| entity-header )

CRLF

[ message-body ]

5.4.1. Request-Line (Строка запроса)

Request-Line начинается с метки метода, за которым следует Request-URI и версия протокола, заканчивающаяся CRLF. Элементы разделены символами SP. Появление символов CR или LF, кроме заключительной последовательности CRLF, запрещено.

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

5.4.1.1. Method (Метод)

Регистр символа слова, обозначающего метод, является существенным.

Method ::= "OPTIONS"

| "GET"

| "HEAD"

| "POST"

| "PUT"

| "DELETE"

| "TRACE"

| extension-method

extension-method ::= token

Поддержка методов GET и HEAD является обязательной для реализации сервера.

5.4.1.2. Request-URI (URI запроса)

Request-URI определяет ресурс, к которому применяется запрос.

Символ “*” показывает, что запрос должен применяться не к отдельному ресурсу, а к серверу вцелом.

Request-URI ::= "*" | absoluteURI | abs_path

5.4.2. Идентификация ресурса

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

5.4.2.1. Если Request-URI является absoluteURI, тогда имя узла является частью Request-URI, и поле Host должно игнорироваться.

5.4.2.2. Если Request-URI не является absoluteURI, и запрос включает поле заголовка Host, узел определяется значением Host.

5.4.2.3. Если узел, определенный с помощью правил 5.4.2.1 и 5.4.2.2., не является действительным узлом на сервере, сервер должен выдать ответ 400.

5.4.3. Поля заголовка запроса.

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

request-header ::= Accept

| Accept-Charset

| Accept-Encoding

| Accept-Language

| Authorization

| From

| Host

| If-Modified-Since

| If-Match

| If-None-Match

| If-Range

| If-Unmodified-Since

| Max-Forwards

| Proxy-Authorization

| Range

| Referer

| User-Agent

5.5. Ответ

После получения и обработки сообщения запроса сервер отвечает сообщением ответа:

Response ::= Status-Line

*( general-header

| response-header

| entity-header )

CRLF

[ message-body ]

5.5.1. Status-Line (Строка статуса)

Строка статуса содержит версию протокола и дополнительную текстовую фразу. Строка статуса не может разрываться символами CR или LF.

Status-Line ::= HTTP-Version SP Status-Code SP Reason-Phrase CRLF

5.5.1.1. Status-Code (код статуса)

Status-Code ::= "100" ; Продолжить

| "101" ; Коммутируемые протоколы

| "200" ; OK

| "201" ; Создан

| "202" ; Принят

| "203" ; Ненадежная информация

| "204" ; Нет содержимого

| "205" ; Переустановить содержимое

| "206" ; Частичное содержимое

| "300" ; Много выборов

| "301" ; Перемещен на постоянный срок

| "302" ; Временно перемещен

| "303" ; См. другие

| "304" ; Не изменен

| "305" ; Используй прокси

| "400" ; Плохой запрос

| "401" ; Неавторизован

| "402" ; Требуется оплата

| "403" ; Запрещено

| "404" ; Не найдено

| "405" ; Метод не разрешен

| "406" ; Неприменим

| "407" ; Требуется идентификация на прокси

| "408" ; Тайм-аут запроса

| "409" ; Конфликт

| "410" ; Ушел

| "411" ; Требуется длина

| "412" ; Ошибка предварительной обработки

| "413" ; Сущность запроса слишком велика

| "414" ; URI запроса слишком велико

| "415" ; Тип информации не поддерживается

| "500" ; Внутренняя ошибка сервера

| "501" ; Не реализовано

| "502" ; Плохой шлюз

| "503" ; Служба недоступна

| "504" ; Тайм-аут шлюза

| "505" ; Версия HTTP не поддерживается

| extension-code

extension-code ::= 3DIGIT

Reason-Phrase ::= *

Первая цифра поля Status-Code определяет класс ответа. Возможные значения приведены в табл. 2.

Таблица 2

Первая цифра поля Status-Code.

От реализаций HTTP не требуется различать значения всех указанных кодов статуса. Но реализации должны различать класс статуса (первую цифру кода). Нераспознанный ответ любого класса должен обрабатываться как код x00 данного класса, но не должен кэшироваться.

5.5.2. Поля заголовка ответа

response-header ::= Age

| Location

| Proxy-Authenticate

| Public

| Retry-After

| Server

| Vary

| Warning

| WWW-Authenticate

Поля заголовка ответа позволяют серверу передать дополнительную информацию, которая не может быть передана в строке статуса Status-Line.

5.6. Сущность

Сущность состоит из полей заголовка сущности и необязательного тела сущности.

5.6.1. Поля заголовка сущности

entity-header ::= Allow

| Content-Base

| Content-Encoding

| Content-Language

| Content-Length

| Content-Location

| Content-MD5

| Content-Range

| Content-Type

| ETag

| Expires

| Last-Modified

| extension-header

extension-header ::= message-header

5.6.2. Тело сущности

Формат и кодирование тела сущности определяется значением полей заголовка сущности.

entity-body ::= *OCTET

5.6.2.1. Тип

Тип данных тела сущности определяется полями заголовка Content-Type и Content-Encoding.

entity-body ::= Content-Encoding( Content-Type( data ) )

Поле Content-Type определяет тип информации.

Поле Content-Encoding должно присутствовать обязательно.

Если поле Content-Type отсутствует, по умолчанию принимается тип информации "application/octet-stream".

5.6.2.2. Длина тела сущности - это длина тела сообщения после удаления транспортного кодирования.

5.7. Соединения

5.7.1. Стойкие соединения

Принцип стойких соединений TCP, в отличие от использования отдельных соединений TCP на каждый отдельный цикл запрос клиента - ответ сервера, предполагает использование одного соединения TCP для нескольких обращений к серверу (даже к нескольким URL, если они расположены на одном сервере).

Использование стойких соединений является необязательным.

5.7.1.1. Общее функционирование

В версии 1.1 протокола HTTP стойкие соединения используются по умолчанию.

Стойкие соединения предоставляют механизм, по которому клиент и сервер могут выдавать сигнал о закрытии соединения TCP. Для этого используется поле заголовка Connection. После того, как было просигнализировано закрытие, клиент не должен передавать запросы по этому соединению.

5.7.1.1.1. Согласование

Если сервер хочет закрыть соединение, он должен сигнализировать об этом в поле Connection. Если клиент хочет закрыть соединение, он должен сигнализировать об этом в поле Connection.

5.7.1.1.2. Перекачка

Клиент, поддерживающий стойкие соединения, может "перекачивать" свои запросы, то есть высылать несколько запросов, не дожидаясь ответов на каждый запрос. Сервер должен высылать ответы в порядке получения запросов.

5.7.1.2. Прокси

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

5.7.1.3. Требования к реализации

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

Сервер HTTP версии 1.1 при обработке запроса клиента HTTP версии 1.0 (или более раннего) не должен передавать ответ 100. Он должен либо дождаться окончания обработки запроса, либо преждевременно закрыть соединение.

При получении метода в соответствии с разделом 6.8 от клиента HTTP версии 1.1 сервер HTTP версии 1.1 должен либо выдать ответ 100 и продолжить чтение входного потока, либо выдать сообщение об ошибке. При выдаче сообщения об ошибке сервер не должен выполнять запрошенный метод.

5.8. Определения методов

5.8.1. Безопасные и идемпотентные методы

5.8.1.1. Безопасные методы

Безопасными называют методы GET (п. 5.8.3) и HEAD (п. 5.8.4). Они всегда означают действия получения, в которых клиент не отвечает за непредвиденный побочный эффект от их выполнения, в отличие от методов POST (п. 5.8.5), PUT (п. 5.8.6) и DELETE (п. 5.8.7).

5.8.1.2. Идемпотентные методы

Идемпотентными называют методы GET (п. 5.8.3), HEAD (п. 5.8.4), PUT (п. 5.8.6) и DELETE (п. 5.8.7), для которых побочный эффект от выполнения нескольких идентичных запросов будет равен побочному эффекту от выполнения одного запроса.

5.8.2. Метод OPTIONS

Метод OPTIONS представляет собой запрос информации о факультативных возможностях соединения, доступных в цепочке запрос/ответ для данного запрашиваемого URI. Данный метод позволяет клиенту определить возможности и (или) требования, связанные с данным ресурсом, а также возможности сервера без выполнения действий над ресурсом.

Если в поле Request-URI установлен символ “*”, запрос относится к серверу в целом.

Если запрос OPTIONS проходит через прокси, прокси должен исправить запрос, исключив те опции, которые относятся к возможностям прокси, и которые не могут быть получены через этот прокси.

На запрос с методом OPTIONS сервер должен выдать ответ 200.

5.8.3. Метод GET

Метод GET позволяет получить любую информацию (в форме сущности), указанную полем Request-URI.

Если сообщение запроса содержит поля заголовка If-Modified-Since, If-Match, If-None-Match или If-Range, метод GET называют условным ("conditional GET").

Если сообщение запроса содержит поле заголовка Range, метод GET называют частичным ("partial GET").

5.8.4. Метод HEAD

Метод HEAD идентичен методу GET за исключением того, что сервер не должен возвращать тело сообщения в ответе.

5.8.5. Метод POST

Метод POST используется для выполнения запроса, в результате которого сервер назначения принимает содержащуюся в запросе сущность, как новую придаточную часть ресурса, определяемого Request-URI в строке запроса Request-Line.

5.8.6. Метод PUT

Метод PUT используется для выполнения запроса, в результате которого сущность, содержащаяся в запросе, сохраняется под указанным Request-URL.

Если создан новый ресурс, сервер должен выдать ответ 201.

Получатель запроса не должен игнорировать поля заголовка Content-* (Например, Content-Range), которые он не понимает или не поддерживает, а должен выдать ответ 501.

В случае невозможности сохранения сущности под указанным URI, сервер не должен сохранять сущность под другим URI, а должен выдать ответ 301.

5.8.7. Метод DELETE

Метод DELETE используется для выполнения запроса, в результате которого сервер удаляет ресурс, идентифицируемый Request-URI.

Сервер может не поддерживать данный метод вообще, либо не поддерживать его для отдельных ресурсов и типов ресурсов.

5.8.8. Метод TRACE

Метод TRACE используется для организации удаленного шлейфа для сообщения запроса. Окончательный получатель запроса должен вернуть данный запрос в теле сущности ответа 200.

Запрос TRACE не должен включать сущность.

Ответы на данный запрос не должны кэшироваться.

5.9. Идентификация доступа

Механизм идентификации клиента не обязателен для реализации.

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

Сообщение ответа 401 используется сервером-источником для начала процедуры идентификации клиента. Данный ответ должен содержать поле заголовка WWW-Authenticate, содержащее как минимум один вызов, применимый к запрошенному ресурсу.

auth-scheme ::= token

auth-param ::= token "=" quoted-string

challenge ::= auth-scheme 1*SP realm *( "," auth-param )

realm ::= "realm" "=" realm-value

realm-value ::= quoted-string

Атрибут realm (область), являющийся нечувствительным к регистру символов, должен присутствовать во всех вызовах процедуры идентификации независимо от схемы. Значение realm-value совместно с каноническим URL корня определяет защищаемую область.

Клиент, желающий выполнить процедуру идентификации, должен после получения ответа 401 или 411 (п. 3.4.2, табл.1) выдать запрос с полем заголовка Authorization. Значение поля Authorization должно состоять из мандатов (credentials), содержащих идентифицирующую информацию о клиенте для указанной в идентификационном вызове защищаемой области.

credentials ::= basic-credentials

| auth-scheme #auth-param

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

Если сервер не принимает запрос с мандатами, он может выдать ответ 401 (п. 3.4.2, табл.1). При этом ответ 401 должен содержать поле заголовка WWW-Authenticate.

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

Прокси должен быть абсолютно прозрачен для процедуры идентификации клиента.

5.9.1. Первичная схема идентификации

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

Пример вызова, выдаваемого сервером для начала процедуры идентификации:

WWW-Authenticate: Basic realm="WallyWorld"

Ответный запрос клиента содержит мандат, состоящий из идентификатора и пароля пользователя, разделенных двоеточием и закодированным в кодировке base64.

basic-credentials ::= "Basic" SP basic-cookie

basic-cookie ::= <закодированный в base64 user-pass,

ограниченного до 76 символов на строка>

user-pass ::= userid ":" password

userid ::= *

password ::= *TEXT

Пример ответного запроса клиента:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

5.10. Согласование содержимого

Согласование содержимого представляет собой механизм для выбора клиентом наиболее подходящего ему представления ресурса. Любой ответ, содержащий тело сущности, может быть предметом согласования содержимого.

Согласование содержимого может быть двух типов: управляемое сервером и управляемое клиентом.

5.10.1. Управляемое сервером согласование содержимого

В случае управляемого сервером согласования данных сервер на основе данных запроса делает предположение о наилучшем для клиента типе информации для данного ресурса. Для согласования содержимого сервером используются следующие поля заголовка запроса пользователя:

Accept, Accept-Charset, Accept-Encoding, Accept-Language, User-Agent.

В случае управляемого сервером согласования данных сервер-источник должен включать в каждый кэшируемый ответ поле Vary.

5.10.2. Управляемое клиентом согласование содержимого

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

5.10.3. Прозрачное согласование

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

5.11. Функционирование кэша и прокси

5.11.1. Ответы с кодом статуса 206 не должны кэшироваться.

5.11.2. Кэш и прокси не должны изменять или добавлять ни в запросе ни в ответе поля Content-Location, ETag, Expires, Last-Modified.

5.11.3. В ответе, содержащем директиву Cache-Control со значением no-transform, и в любом запросе кэш и прокси не должны изменять или добавлять следующие поля:

Content-Encoding, Content-Length, Content-Range, Content-Type.

Если кэш или прокси изменяют или добавляют эти поля, они должны при этом добавить предупреждение 14 (см. п. 5.12.45, табл. 3), если только в данном сообщении уже нет предупреждения 14.

5.11.4. Выполнение проверки актуальности

Если кэш выполняет запрос проверки актуальности к серверу, и сервер выдает ответ 304, кэш должен составить и отправить ответ клиенту, а также заменить поля заголовков хранящихся в кэше позиций (включая поля, указанные в п. 5.11.2. и 5.11.3.) на значения, полученные в ответе 304.

5.11.5. Кэш, который получает неполный ответ (например, с меньшим количеством байт данных, чем указано в поле Content-Length заголовка), в случае, если он сохраняет данный ответ, должен его обрабатывать как частичный. Частичные ответы могут комбинироваться в кэше. Кэш должен выдавать частичный ответ только используя код статуса 206.

5.11.6. Кэш не должен обрабатывать ответы, в которых в части rel_path URL содержатся символы "?", если только в них не указано точное время истечения.

5.12. Определения полей заголовка

5.12.1. Accept

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

Accept ::= "Accept" ":"

#( media-range [ accept-params ] )

media-range ::= ( "*/*"

| ( type "/" "*" )

| ( type "/" subtype )

) *( ";" parameter )

accept-params ::= ";" "q" "=" qvalue *( accept-extension )

; параметры указывают относительный фактор качества

; (от 0 до 1). По умолчанию - 1.

accept-extension ::= ";" token [ "=" ( token | quoted-string ) ]

Символ “*” используется для группирования типов информации в диапазоны. При этом "*/*" означает все типы данных, а "тип/*" - все подтипы данного типа.

Пример:

Accept: text/plain; q=0.5, text/html,

text/x-dvi; q=0.8, text/x-c

Будет означать: предпочтительными типами информации являются text/html и text/x-c, но если таких нет, тогда нужно выслать сущность с типом text/x-dvi. А если и такого нет, тогда выслать text/plain.

5.12.2. Accept-Charset

Поле заголовка запроса Accept-Charset используется для указания наборов символов, приемлемых в ответе:

Accept-Charset ::= "Accept-Charset" ":"

1#( charset [ ";" "q" "=" qvalue ] )

Например:

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Если данное поле отсутствует, считается, что для клиента приемлем любой набор символов.

5.12.3. Accept-Encoding

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

Accept-Encoding ::= "Accept-Encoding" ":"

#( content-coding )

Например:

Accept-Encoding: compress, gzip

5.12.4. Accept-Language

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

Accept-Language ::= "Accept-Language" ":"

1#( language-range [ ";" "q" "=" qvalue ] )

language-range ::= ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

По умолчанию определитель качества q=1.

Пример:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

означает: я предпочитаю датский, но также приемлемыми являются британский английский и другие типы английского.

5.12.5. Accept-Ranges

Поле ответа Accept-Ranges позволяет серверу указать приемлемые диапазоны в запросах к ресурсу.

Accept-Ranges ::= "Accept-Ranges" ":" acceptable-ranges

acceptable-ranges ::= 1#range-unit | "none"

Клиент может генерировать запросы с диапазоном байтов, даже если он не получил ответа с таким полем в заголовке.

5.12.6. Age

Поле ответа Age содержит приблизительный период времени, прошедший с момента отправки ответа сервером-источником.

Age ::= "Age" ":" age-value

age-value ::= delta-seconds

Значения Age должны рассчитываться кэшем следующим образом:

apparent_age = max(0, response_time - date_value);

corrected_received_age = max(apparent_age, age_value);

response_delay = response_time - request_time;

corrected_initial_age = corrected_received_age + response_delay;

resident_time = now - response_time;

current_age = corrected_initial_age + resident_time;

где

age_value - это значение Age из заголовка данного ответа,

полученного кэшем

date_value - значение Data заголовка сообщения от сервера-

источника

request_time - местное время, когда кэш сделал запрос, в результате

которого появилось данное сообщение

response_time - местное время, когда кэш получил ответ

now - текущее местное время

Если кэш получает значение большее, чем значение наибольшего положительного целого, с которым он может работать, либо при переполнении во время вычисления Age, он должен передать поле Age со значением 2147483648 (2 ^ 31). Поле Age должно присутствовать в каждом ответе.

5.12.7. Allow

Поле заголовка Allow содержит список методов, поддерживаемых для ресурса, указанного в Request-URI. Поле заголовка Allow должно присутствовать в ответе 501.

Allow ::= "Allow" ":" 1#method

Например:

Allow: GET, HEAD, PUT

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

5.12.8. Authorization

Клиент, которому необходимо идентифицироваться, - обычно после ответа 401 (п.4.4.2, табл. 1), - может выполнить процедуру идентификации, включив заголовок ответа поля Authоrization. Содержимое поля Authorization состоит из информации, идентифицирующей права клиентского агента на область запрашиваемых им ресурсов.

Authorization = "Authorization" ":" credentials

5.12.9. Cache-Control

Общее поле Cache-Control используется для определения директив, которым должны подчиняться все кэши в цепочке запрос/ответ.

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

Cache-Control ::= "Cache-Control" ":" 1#cache-directive

cache-directive ::= cache-request-directive

| cache-response-directive

cache-request-directive ::=

"no-cache" [ "=" 1#field-name ]

| "no-store"

| "max-age" "=" delta-seconds

| "max-stale" [ "=" delta-seconds ]

| "min-fresh" "=" delta-seconds

| "only-if-cached"

| cache-extension

cache-response-directive ::=

"public"

| "private" [ "=" 1#field-name ]

| "no-cache" [ "=" 1#field-name ]

| "no-store"

| "no-transform"

| "must-revalidate"

| "proxy-revalidate"

| "max-age" "=" delta-seconds

| cache-extension

cache-extension ::= token [ "=" ( token | quoted-string ) ]

5.12.10. Connection

Общее поле заголовка Connection позволяет отправителю определить факультативные возможности для отдельного соединения транспортного уровня, которые не должны передаваться серверами прокси по дальнейшим соединениям транспортного уровня.

Connection-header ::= "Connection" ":" 1#(connection-token)

connection-token ::= token

Перед тем, как направить сообщение с полем Connection, для каждого маркера connection-token в данном поле сервер должен удалить поле (поля) заголовка с соответствующим именем.

Специальный маркер "close" является сигналом закрытия соединения после выполнения данного запроса.

Приложения HTTP версии 1.1, которые не поддерживают стойкие соединения, должны включать маркер "close" в каждое сообщение.

5.12.11. Content-Base

Поле заголовка сущности Content-Base может использоваться для идентификации базового URI, используемого совместно с относительными URL внутри сущности.

Content-Base ::= "Content-Base" ":" absoluteURI

Если поле Content-Base отсутствует, базовый URI сущности определяется либо ее полем Content-Location (если Content-Location URI - это абсолютный URI), либо URI, использованным для инициирования запроса.

5.12.12. Content-Encoding

Поле заголовка сущности Content-Encoding используется как модификатор к типу информации. Присутствие данного поля показывает, что к телу сущности было применено дополнительное кодирование содержимого.

Content-Encoding ::= "Content-Encoding" ":" 1#content-coding

Если было применено несколько кодирований, они должны быть перечислены в порядке, в котором они применялись.

5.12.13. Content-Language

Поле заголовка сущности Content-Language описывает естественный язык информации в теле сущности.

Content-Language ::= "Content-Language" ":" 1#language-tag

5.12.14. Content-Length

Поле заголовка сущности Content-Length указывает на размер тела сообщения, в октетах. В случае метода HEAD поле заголовка содержит размер тела сообщения, которое могло бы быть послано клиенту в случае использования метода GET.

Content-Length ::= "Content-Length" ":" 1*DIGIT

5.12.15. Content-Location

Поле заголовка сущности Content-Location может быть использовано для указания местоположения ресурса для сущности.

Content-Location ::= "Content-Location" ":"

( absoluteURI | relativeURI )

5.12.16. Content-MD5

Поле заголовка сущности Content-MD5, в соответствии с RFC 1864 [25], содержит контрольный код MD5 для тела сущности, обеспечивая проверку целостности сообщения "из конца в конец".

Content-MD5 ::= "Content-MD5" ":" md5-digest

md5-digest ::= < 128 bit MD5 в соответствии с RFC 1864[25],

закодированный в 64Base>

5.12.17. Content-Range

Поле заголовка сущности Content-Range посылается с частичным телом сущности, чтобы указать, где частичное тело должно быть вставлено в полное тело сущности. Так же оно указывает общий размер полного тела сущности.

Content-Range ::= "Content-Range" ":" content-range-spec

content-range-spec ::= byte-content-range-spec

byte-content-range-spec ::= bytes-unit SP first-byte-pos "-"

last-byte-pos "/" entity-length

entity-length ::= 1*DIGIT

5.12.18. Content-Type

Поле заголовка сущности Content-Type указывает на тип информации тела сущности.

Content-Type ::= "Content-Type" ":" media-type

5.12.19. Date

Поле заголовка сущности Date представляет дату и время генерации сообщения.

Date ::= "Date" ":" HTTP-date

Данное поле должно быть включено во все ответы.

5.12.20. ETag

Поле заголовка сущности ETag определяет тег сущности для размещенной сущности.

ETag ::= "ETag" ":" entity-tag

Например:

ETag: "xyzzy"

ETag: W/"xyzzy"

ETag: ""

5.12.21. Expires

Поле заголовка сущности Expires указывает дату и время, после который данный ответ будет считаться устаревшим. Формат этого поля должен соответствовать RFC 1123 [18].

Expires ::= "Expires" ":" HTTP-date

Если формат поля не соответствует данным требованиям, клиенты и кэши должны обрабатывать такой ответ как устаревший.

5.12.22. From

Поле заголовка запроса From должно содержать адрес электронной почты Internet пользователя, контролирующего программу-клиент.

From ::= "From" ":" mailbox

5.12.23. Host

Поле заголовка запроса Host указывает узел Internet и номер порта ресурса, который запрашивается.

Host ::= "Host" ":" host [ ":" port ]

Клиент HTTP версии 1.1. должен включать поле Host во все запросы. Если поле Host отсутствует, прокси должен добавить это поле.

Сервер HTTP версии 1.1. должен отвечать сообщением 400 при получении запроса с отсутствующим полем Host.

5.12.24. If-Modified-Since

Поле заголовка запроса If-Modified-Since используется с методом GET, чтобы сделать его условным: если запрошенный вариант не был изменен с указанного времени, сущность не будет возвращена. Вместо этого будет возвращен ответ 304.

If-Modified-Since ::= "If-Modified-Since" ":" HTTP-date

Если формат даты неправильный, сервер должен выдать ответ на обычный (не условный) GET.

5.12.25. If-Match

Поле заголовка запроса If-Match используется вместе с методом, позволяющем сделать его условным. Клиент, у которого есть одна или более ранее полученных сущностей, может проверить, является ли одна из них текущей версией, включив соответствующий список тегов сущностей в данное поле. Значение "*" обозначает любую текущую сущность.

If-Match ::= "If-Match" ":" ( "*" | 1#entity-tag )

Если хотя бы один тег сущностей совпадает с тегом сущности, которая могла бы быть возвращена на подобный безусловный запрос GET, либо если стоит символ “*” и существует текущая версия данного ресурса, тогда сервер может выполнить запрошенный метод.

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

При отсутствии совпадения тегов, либо при отсутствии текущей версии сущности, сервер не должен выполнять указанный метод, а должен возвратить ответ 412.

5.12.26. If-None-Match

Поле заголовка запроса If- None-Match используется с методом, чтобы сделать его условным. Использование данного поля подобно полю If-Match.

Если ни один из тегов сущностей не совпадает с тегом сущности, которая могла бы быть возвращена на подобный безусловный запрос GET, либо если стоит символ “*” и не существует текущая версия данного ресурса, тогда сервер может выполнить запрошенный метод.

If-None-Match ::= "If-None-Match" ":" ( "*" | 1#entity-tag )

5.12.27. If-Range

Если у клиента есть в кэше частичная копия сущности, и он хочет получить актуальную целую сущность в свой кэш, он может использовать условный GET с полем If-Range.

If-Range ::= "If-Range" ":" ( entity-tag | HTTP-date )

Данный запрос будет означать: если сущность не изменилась, отправьте недостающую часть. В противном случае, отправьте целую сущность. Таким образом, сервер должен выдать ответ 206 либо 200.

5.12.28. If-Unmodified-Since

Поле заголовка запроса If- None-Match используется с целью сделать его условным. Если запрошенный ресурс не был изменен с указанного времени, сервер должен выполнить запрошенную операцию так, как если бы поле If-Unmodified-Since отсутствовало.

If-Unmodified-Since ::= "If-Unmodified-Since" ":" HTTP-date

Если запрошенный вариант был изменен с указанного времени, сервер должен выдать ответ 412.

5.12.29. Last-Modified

Поле сущности Last-Modified указывает дату и время, в которое, по сведениям сервера-источника, данный вариант был изменен последний раз.

Last-Modified ::= "Last-Modified" ":" HTTP-date

5.12.30. Location

Поле ответа Location используется для перенаправления получателя на иной адрес, чем Request-URI для выполнения запроса или идентификации нового ресурса.

Для ответа 201 в данном поле указывается новый созданный ресурс. Для ответов 3хх Location указывает на URL для автоматического перенаправления.

Location ::= "Location" ":" absoluteURI

5.12.31. Max-Forwards

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

Max-Forwards ::= "Max-Forwards" ":" 1*DIGIT

Значение поля представляет собой десятичное число, показывающее остающееся число разрешенных пересылок сообщения.

Характеристики

Список файлов стандарта