РД 45.134-2000, часть 9
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 :: = *<TEXT, включая CR, LF>
Первая цифра поля Status-Code определяет класс ответа. Возможные значения приведены в табл. 2.
Таблица 2
Первая цифра поля Status-Code.
-
1хх
Информационный
Запрос получен, продолжаю процесс
2хх
Успех
Команда получена, понята и принята
3хх
Перенаправление
Должны быть предприняты дальнейшие действия для завершения запроса
4хх
Ошибка клиента
Запрос содержит синтаксическую ошибку или не может быть выполнен
5хх
Ошибка сервера
Сервер не может выполнить очевидно правильный запрос.
От реализаций 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 :: = *<TEXT кроме ":">
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 используется вместе с методом, позволяющем сделать его условным. Клиент, у которого есть одна или более ранее полученных сущностей, может проверить, является ли одна из них текущей версией, включив соответствующий список тегов сущностей в данное поле. Значение "* " обозначает любую текущую сущность.