TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Таблица 19.5 Заголовки элементов HTTP

Заголовки элементов	Описание
Allow: метод	Перечисление поддерживаемых ресурсом методов, например: Allow. GET, HEAD
Content- Encoding: кодирование содержимого	Для сжатого или зашифрованного содержимого; указывает на использованный алгоритм, например: Content-Encoding: x-gzip
Content-Length: длина	Описывает длину тела пересылаемого документа, например: Content-Length: 2048
Content-Type: тип носителя	Определены IANA, например: Content-Type, text/html
Expires: дата	Элемент недостоверен после указанной даты.
Last-Modified: дата	Время последней модификации элемента.

■ В сообщении первыми стоят главные заголовки как в запросах, так и в ответах (таблица 19.2).

■ Затем следуют заголовки, специфичные для запросов (таблица 19.3) или ответов (таблица 19.4).

■ Наконец последними стоят заголовки элементов, которые обеспечивают детальное описание данного элемента (таблица 19.5).

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

19.8.3 Коды состояния

Коды состояния используются подобно электронной почте и пересылке файлов (FTP). Наиболее распространенные значения кодов:

1xx	Информация. Не используется, но зарезервирован для применения в будущем.
2xx	Успешно. Запрошенная операция была успешно получена, понята и принята для исполнения.
3xx	Перенаправление. Для полного завершения требуются дополнительные действия.
4xx	Ошибка клиента. Запрос имеет синтаксическую ошибку или не может быть выполнен.
5xx	Ошибка сервера. Сервер не смог выполнить корректный запрос.

Более детальные сведения обозначаются дополнительными кодами.

19.9 Продолжение совершенствования

В ответ на требования пользователей по обеспечению больших функциональных возможностей HTTP и HTML постоянно совершенствуются. На момент написания книги шла разработка стандартов для обеспечения безопасности взаимодействий клиент/сервер и для создания действительно защищенных коммерческих систем. Других достижений можно ожидать в области определения и реализации независимой от размещения ресурсов схемы именования (Uniform Resource Names — URN), поскольку существует проблема потери ссылки при перемещении документа на другой компьютер или в другой каталог.

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

19.10 Дополнительная литература

RFC 1738 содержит описание URL. RFC 1630 — это техническое руководство по Universal Resource