Сети и системы телекоммуникаций. Погонин В.А - 86 стр.

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

OPTIONS * HTTP/1.1 Host: www.ics.uci.edu:8001
после соединения с портом 8001 хоста "www.ics.uci.edu".
Первоначальный сервер должен декодировать Request-URI, чтобы правильно интерпретиро-
вать запрос. Серверам следует отвечать на недопустимые Request-URI соответствующим кодом
состояния.
В запросах, пересылаемых прокси-сервером, часть "abs_path" URI запроса (Request-URI) ни-
когда не должна перезаписываться, за исключением случая, отмеченного выше, когда пустой
abs_path заменяется на "*", независимо от внутренней реализации прокси-сервера.
Правило "ничто не перезаписывать" предохраняет прокси-сервера от изменения значения
запроса, в котором первоначальный сервер неправильно использует не зарезервированные сим-
волы URL для своих целей.
Первоначальные HTTP/1.1 сервера должны учитывать, что точный ресурс, идентифицируемый
интернет-запросом определяется путем исследования запрашиваемого URI (Request-URI) и поля
заголовка Host.
Первоначальный сервер, который не различает ресурсы по запрошенному хосту (host), может
игнорировать значение поля заголовка Host.
Первоначальный сервер, который различает ресурсы на основании запрошенного хоста (host)
(иногда называемые виртуальными хостами или vanity hostnames) должен пользоваться следую-
щими правилами для определения ресурса, запрошенного в HTTP/1.1 запросе:
1 Если Request-URI – это absoluteURI, то хост – это часть Request-URI. Любые значения поля
заголовка Host в запросе должны игнорироваться.
2 Если Request-URI – не absoluteURI, а запрос содержит поле заголовка Host, то хост опреде-
ляется значением поля заголовка Host.
3 Если хоста, определенного правилами 1 или 2 не существует на сервере, кодом состояния
ответа должен быть 400 (Испорченный Запрос, Bad Request).
Получатели HTTP/1.0 запроса, в котором отсутствует поле заголовка Host, могут попытаться
использовать эвристику (например, исследовать путь в URI на предмет уникальности на каком-
либо из хостов) для определения какой именно ресурс запрашивается.
Поля заголовка запроса позволяют клиенту передать серверу дополнительную информацию о
запросе и о самом клиенте. Эти поля действуют как модификаторы запроса с семантикой, экви-
валентной параметрам вызова методов в языках программирования:
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
Множество имен полей заголовка запроса (Request-header) может быть надежно расширено
только в сочетании с изменением версии протокола. Однако, новые или экспериментальные поля
заголовка могут получить семантику полей заголовка запроса (Request-header), если все стороны
соединения распознают их как поля заголовка запроса (Request-header). Нераспознанные поля за-
головка обрабатываются как поля заголовка объекта (entity-header).
9.4.6. ОТВЕТ (RESPONSE)
После получения и интерпретации сообщения запроса, сервер отвечает сообщением HTTP от-
вета:
Response = Status-Line *( general-header | response-header |
entity-header )
CRLF [ message-body ]
Первая строка ответа – это строка состояния (Status-Line). Она состоит из версии протокола
(HTTP-Version), числового кода состояния (Status-Code) и поясняющей фразы (Reason-Phrase)

Страницы