Различные изменения

В НТТР/1.1 по сравпепию с НТТР/1.0 есть и другие пезпачительпые изменения. Мы рассмотрим различные изменения, не вошедших в рассмотренный набор категорий, разделив эти изменения на три части: относящиеся к методам, к заголовкам и к кодам ответов. Эти измепепия обсуждаются отдельпо, чтобы не отвлекать внимание от более важных изменений рассмотренных в этой главе рапьше.

, относящиеся к методам

Семаптика отдельных методов НТТР/1.0 была изменена незначительно. В некоторых случаях была уточнена иптернретация эгих методов. Изменения коснулись методов HEAD, PUT, DELETE и CONNECT.

НЕЗНАЧИТЕЛЬНОЕ ИЗМЕНЕНИЯ МЕТОДА HEAD

В НТТР/1.0 нельзя было модифицировать запрос HEAD условными заголовками (такими как If-Modified-Since), в НТТР/1.1 иег таких ограпичепий. Условные заголовки в НТТР/1.1 можно использовать с любым методом. Спецификация НТТР/1.1 придерживается прииципа вводить ограничения только тогда, когда следует, и приводить копкретпые обоснования для любых введенных ограничений.

УТОЧНЕНИЯ МЕТОДА PUT

Метод PUT был частично описан в RFC 1945, как часть НТТР/1.0. Последующие дискуссии в HTTP Working Group привели к общему решению о его формальном определении в качестве метода НТТР/1.1. Web-сервер, обрабатывающий запрос PUT, проверяет URI запроса, чтобы определить будет ли запрос модифицировать существующий ресурс или создавать новый. Web-сервер должен проверить права доступа пользователя, прежде чем применять данный метод к ресурсу. В формальном определении метода были добавлены отдельные требования к Web-серверам и кэширующим прокси-серверам. Например, Web-сервер должен отвечать 201 Created, если ресурс был создан в результате запроса с методом PUT. Если ресурс, указанный в методе PUT (гакже как POST и DELETE) был помещен в кэш, кэшированпый ответ должен быть помечен как устаревший. Кэширующий прокси-сервер, который заметит запрос с методом, допускающим изменение ресурса на сервере-источнике, должен отметить как неактуальные любые элементы кэша, связанные с этим ресурсом.

В следующем примере запрос с методом PUT используется для создания или модификации ресурса /foobar/foo.html:

PUT /foobar/foo.html НТТР/1.1 User-Agent: Mozilla/2.0 Authorization: Basic ZHeadFuaYow29PinWU= Content-Type: text/html Content-Length: 433 Host: bar.com

<433 байта возможно нового foo.html>

Этот запрос включает информацию о типе содержания и его длине, также как идентификационные данные в заголовке Authorization. Идентификационные данные нужны Web-cepвepy, чтобы убедиться, что данный пользователь имеет необходимые права доступа для модификации или создания ресурса. Если полномочия достаточны, сервер создает или модифицирует /foobar/foo.html, а также возвращает ответ 200 ОК.

Сравнение методов PUT и POST. Различия. В процессе формализации определения метода PUT возникали вопросы о различии методов PUT и POST. Чтобы понять разницу между методами PUT и POST, нужно рассмотреть, как осуществляется интерпретация URI в запросе. PUT обязывает сервер применить запрос только к данному URI и, если он не может этого сделать, вернуть ответ, относящийся к классу переадресации. Ресурс может быть создан или изменен. Ресурс в методе POST ссылается на программу, которая должна будет обработать данные, включенные в содержимое сообщения POST. Это тот случай, когда пользователь заполняет форму как составную часть запроса.

МЕТОД DELETE. ФОРМАЛИЗАЦИЯ

Как и PUT, метод DELETE рассматривался в приложении к RFC 1945, но не был формально определен. Метод DELETE приводит к удалению ресурса, ассоциированного с запрашиваемым URI, если запрос не аннулируется но каким-то другим причинам на Web-cepBepe. Web-сервер, например, может проверить права доступа инициатора запроса и принять решеиие не удалять ресурс. В этом случае, сервер должен будет сообщить запрашивающему клиенту, что запрос не припят, возвратив огвег 401 Unauthorized или 403 Forbidden.

В НТТР/1.1 требования к компонентам, связанные с реакцией на метод DELETE, определены ясно. Например, в протоколе определены коды ответов, которые должен послать Web-сервер, если удаление выполнено успешпо. Прокси-сервер, получивший запрос DELETE для ресурса помечает его кэшированную копию как устаревшую.

МЕТОД CONNECT

Метод CONNECT используется для создания «тупиеля» между двумя прокси-серверами и был предложен Ари Луотопепом [Luo97J в 1998 г. в рабочем проекте стандарта (теперь уже устаревшем). Оп не был формально стапдартизоваи. Новый метод — CONNECT — был зарезервирован в НТТР/1.1 в роли «заполнителя» (то есть для гарантии, что этот метод не будет зарезервирован в будущем для како- го-то другого применения). Хотя имя этого метода зарезервировано для будущего применения, одно специфическое применение в RFC уномяпуто — прокси-сервер, в целях обеспечения безопасности, снособеп превратиться в «тупнель». Иначе говоря, прокси-сервер начинает механически ретранслировать сообщение, которое оп получаст. Метод CONNECT в НТТР/1.1 [KL00J используется для инициирования Transport Layer Security (TLS) поверх существующего ТСР-соедипеиия, для прокладки «туннелей» через прокси-серверы.

, относящиеся к заголовкам

Некоторые заголовки НТТР/1.0 были пемного изменены, некоторые новые заголовки были добавлены по узкоспециальным соображениям. Мы рассмотрим эти изменения в трех частях: общие заголовки, заголовки ответов и заголовки содержимого.

ОБЩИЕ ЗАГОЛОВКИ

Если тело сообщения было как-то изменено, то способ измепепия указывается в заголовке Transfer-Encoding, чтобы получатель зпал, как анализировать тело сообщения. В НТТР/1.0 не было гарантии (при отсутствии заголовка Content-Length), что получатель действительно получил то, что было передано отправителем. Кодирование при передаче позволило гараитировать, что получатель получил все, что было отправлено. Заголовок Transfer-Encoding — заголовок промежуточных передач и, таким образом, имеет смысл только для одного текущего соединения.

В результате введения заголовка Transfer-Encoding в НТТР/1.1, по сравнению с НТТР/1.0, изменилось определение НТТР-сообщения (и запроса, и ответа). В НТТР/1.0, чтобы получить тело содержимого, достаточно было удалить только заголовки сообщения, а в НТТР/1.1 исходное сообщение нужно еще и восстановить, применив к нему преобразование, обратное кодированию при передаче.

ЗАГОЛОВКИ ОТВЕТОВ

Один заголовок НТТР/1.0 (Retry-After) был измепеп в НТТР/1.1 и был добавлен новый заголовок Warning.

Заголовок Retry-After рассматривался в приложении к спецификации НТТР/1.0 в контексте несовместимых реализаций протокола. Тем не менее, этот заголовок не стал частью спецификации НТТР/1.0. Оп был введеп в НТТР/1.1 для уточнения семантики кода ответа 503 Service Unavailable. Существуют две причипы обусловливающие этот код ответа: сервер в течение неопределенного времени работает в авто- иомпом режиме, — временно занят и возможно скоро освободится. Если сервер мо- жег сообщить клиенту, что данный сервис, возможно, освободится позже, то клиент может повторить запрос после указанного интервала времени. Зпачепие времени указывается или относительно текущего момента или задается копкретпое зпачепие в будущем. В НТТР/1.1 заголовок Retry-After используется с несколькими ответами, включая 413 Request Entity Too Large (раздел 7.2.3) и ответами переадресации класса (3xx).

Первые сообщения об ошибках в НТТР/1.0 не были предназначены для чтения их человеком. Классы ошибок 4xx и 5xx включают короткие и простые фразы на естественном языке, по из этих фраз нельзя извлечь информацию о возможных корректных действиях. К сожалению, код состояния и строка сообщения появляются в первой строке ответа и поэтому несколько кодов состояния туда пельзя поместить. Многочислеиные коды состояния могли бы запутать получателей. Любая дополнительная информация должиа включаться в отдельные заголовки. Эта ситуация была исправлена в НТТР/1.1 путем введения заголовка Warning. Тенерь вместе с кодом класса предупреждающего сообщения Можно посылать информацию, поясняющую предупреждающее сообщение. Обратите внимание, что эти коды предупреждений не относятся к общим кодам ответов HTTP. Как показано в таблице 7.15, в НТТР/1.1 определено семь кодов предупреждений.

Таблица 7.15. Коды предупреждений НТТР/1.1

Код предупреждения (warning)

Краткое описание

110   Response is stale

111   Revalidation failed

112   Disconnected operation

113   Heuristic expiration

199 Miscellaneous warning

214 Transformation applied

299 Miscellaneous persistent warning

Кэш предупреждает, что возвращенный ответ устарел Неудачная попытка проверить актуальность ответа Кэш отключен от сети

Срок годности определен на основе эвристики Предупреждение для вывода пользователю Кодирование или тип содержания изменены Предупреждение класса 2xx для вывода пользователю

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

Например, предположим, что ресурс был получеп с содержанием, закодированным каким-то одним способом (например, gzip), по промежуточный прокси-сервер преобразовал ответ в другой формат. Было бы полезно указать на этог факт в предупреждающем сообщении, а не просто пересылать ответ дальше в его трансформированном виде. Прокси-сервер может включить заголовок Warning следующим образом:

Warning: 214 Transformation applied

Аналогично, если прокси-сервер собирается вернуть ответ из кэша из-за невозможности установить связь с исходным сервером, прокси-сервер может указать на то, что актуальность данного ответа не подтверждена, следующим образом:

Warning: 111 Revalidation failed

ЗАГОЛОВКИ СОДЕРЖИМОГО

В НТТР/1.0 было описано шесть заголовков содержимого, еще один, Content- Language, был рассмотрен в приложении к RFC 1945. Некоторые из заголовков содержимого НТТР/1.0 были изменены в НТТР/1.1, чтобы извлечь преимущества из его новых возможностей. Например, в НТТР/1.1 уточнено, что к ресурсу может быть применено несколько кодировок содержания в заголовке содержимого Content-Encoding. Web-серверы обязаны проверять, что значение Last-Modified совпадает со временем, сгенерированным ими для значения поля Date в ответе. Если уже после того как ответ был сгенерирован, содержимое было измепепо, то получатель узнает об этом по времени модификации содержимого.

, относящиеся к кодам ответов

При переходе от НТТР/1.0 к НТТР/1.1 почти во всех классах ответов было по несколько кодов, семантика которых была изменена. Мы рассмотрим эти изменения кодов в соответствии с теми классами, к которым они относятся.

КОДЫ ОТВЕТОВ 2XX

Из четырех нрежпих кодов ответов класса 2xx только два были пезпачителыю измепепы. Код ответа 200 OK дополпен небольшим уточнением, что ответы на запросы HEAD не содержат тела сообщения, в отличие от тела содержимого в НТТР/1.0. Иначе говор&, заголовки содержимого могут быть включены.

В коде ответа НТТР/1.0 201 Created было сделано несколько небольших дополнений. Заголовок Location Можно включать в ответ, указывая конкретный URI для созданного ресурса. Ресурс может иметь несколько адресов, и заголовок Location можно использовать, чтобы указать конкретный адрес. В заголовок ответа Можно также включать другие свойства, характерные для данного ресурса, такие как тип содержания.

Из трех новых в НТТР/1.1 кодов ответов класса 2xx, два объясняются здесь. Третий (206 Partial Content) был рассмотрен в разделе 7.4.1. Здесь мы добавляем пояснение относительно кэширования ответов 206 Partial Content.

203 Non-Authoritative Information. Этот новый код ответа используется для указания, что метаданные о ресурсе были получены не от самого Web-сервера, а из других источников. Метаданные вероятно не идентичны тем, которые прислал бы исходный сервер. В тех случаях, когда наличие дополнительных метаданных о ресурсе возможно, протокол разрешает включить эту информацию, но с другим кодом ответа.

205 Reset Content. Новый код ответа в НТТР/1.1 205 Reset Content используется исходным сервером, чтобы помочь агенту пользователя организовать обратную связь с пользователем. В НТТР/1.0 не было возможности это сделать. Предположим, что пользователь передал данные из формы на сервер. Сервер, возвратив код 205, может вызвать очистку формы агентом пользователя, показывая пользователю, что данные формы были приняты сервером. Пользователь может продолжить ввод данных в форму для передачи дополнительных запросов. Это пример изменения протокола, которое помогает агенту пользователя использовать ответ сервера, для информирования пользователя об изменении состояния.

206 Partial Content. Кэши, которые не поддерживают заголовки Range, не должпы кэшировать ответ 206 Partial Content. Такое предупреждение — пример ограничений накладываемых на реализации, которые не поддерживают повое свойство, но легко могут получать ответы с кодами состояний, связанными с повым свойством. Спецификация протокола включает много таких ограничений, но реализации не всегда проходят проверку на соответствие этим ограничениям, что приводит к потенциальным проблемам. Так изменение протокола оказывает воздействие на реализации серверов и клиентов, которые этим изменением не затронуты.

КОДЫ ОТВЕТОВ зхх

Четырьмя повыми кодами ответов в НТТР/1.1 являются 303 See Other, 305 Use Proxy, 306 (Unused) и 307 Temporary Redirect. Коды ответов 303 и 307 были введепы для того, чтобы Web-комиопенты могли определять нужное действие более Точно. Код ответа 305 был введен в промежуточной (не принятой в качестве стандарта) спецификации RFC 2068. Код ответа 306 был предложен в промежуточной версии проекта спецификации протокола, по был удален в процессе стандартизации протокола.

303 See Other. Ответ НТТР/1.0 302 Moved Temporarily включал заголовок Location, указывая агенту пользователя, где действительно может находиться данный ресурс. Ответ 303 See Other похож на код состояния 302 Moved Temporarily, но был добавлен специально, чтобы исправить известную проблему с агентами пользователя, которые некорректно обрабатывали ответ 302. Эго один из примеров эволюции протокола после обнаружения ошибок в существующих реализациях.

307 Temporary Redirect Код ответа 307 Temporary Redirect информирует агента пользователя, что данный ресурс может временно находиться но новому URI, внесенному в заголовок ответа Location. При наличии ответа иереадресации некоторые агеп- гы пользователя ошибочно используют метод запроса GET, чтобы извлечь ресурс по новому URI, независимо от того, какой метод использовался в исходном запросе. И это несмотря на гот факт, что и в RFC 1945, и в одной из промежуточных спецификаций НТТР/1.1 (RFC 2068) говорится яспо, что при переадресации методы запросов не должны изменяться. Переадресация используется в условиях наличия «зеркал» Web-серверов, из-за чего запрос клиента может быть переадресован ближайшей к клиенту «зеркалу». Это спижает нагрузку на отдельный сервер.

305 Use Proxy. Код ответа 305 Use Proxy сообщает запрашивающему компоненту, что запрос надо повторить через указанный прокси-сервер, заданный в заголовке ответа Location. Этот код был первоначально введен, чтобы дать возможность Web-серверу запрещать достуи для всех запросов кроме тех, которые поступают от соответствующего прокси-сервера. Смысл такого решения был в том, чтобы снизить нагрузку на Web-сервер и расположить его так, чтобы оп мог указывать каким прокси-сервером должен пользоваться конкретный клиент. Кроме того, промежуточная спецификация RFC 2068 была недостаточно четкой в том, что касается использования кода ответа 305, и создала возможность появления дыры в системе безопасности. Только один запрос может быть переадресован посредством ответа 305 и такая переадресация может быть сделана только самим Web-cepвером. Если это не так, то существует вероятность наличия агаки типа промежуточного компонента (man-in-the-middle). В этом случае некий промежуточный компонент переадресует запросы на «вражеский» прокси-сервер.

306 (Unused). Ответ 306 был введен в одной из первых версий проекта спецификации HTTP и позже исключен. Версия прокси-сервера компании Netscape расширяла требования для кода ответа 306 Switch Proxy гаким образом, что получатель мог использовать прокси-сервер, указанный в повом заголовке промежуточных передач Set-proxy, для последующих запросов. Дополнение должно было, главным образом, добавить некоторую недостающую функциональность к семантике ответа 305 Use Ргоху и ограничить область применения этого ответа про- кси-серверами, а не Web-серверами. Однако беспокойство о последствиях этого ответа для безопасности (особенно в связи с атакой типа промежуточного компонента) привело к исключению в НТТР/1.1 кода состояния 306. Однако так как простое исключение может означать, что прежние реализации станут не работоспособными, этот код был зарезервирован.

КОДЫ ОТВЕТОВ 4XX

Несколько новых кодов ответов класса 4xx были реализованы в НТТР/1.1. Коды ответов из таблицы 7.10, не обсуждавшиеся до этого, могут быть разбиты на три категории: уточнение, использование возможности согласования в НТТР/1.1 и новые коды для других свойств.

1. Уточняющие коды состояний. В этой категории мы обсудим три новых кода состояния.

405 Method Not Allowed. Код ответа 405 Method Not Allowed был введеп для того, чтобы иметь возможность дать несколько более подробный ответ при отклонении запроса на конкретный ресурс. Вместо того чтобы возвращать более общий код ошибки 403 Forbidden (как это имеет место в НТТР/1.0), сервер перечисляет набор методов, которые разрешены для запрашиваемого URI. Это делается с помощью заголовка содержимого Allow. Заметьте, что сервер обязан это делать, если посылается ответ 405 Method Not Allowed. Отправитель запроса может затем изменить метод запроса. Предположим, что клиент послал запрос TRACE серверу, у которого этот метод не реализоваи. Этот сервер вернет

НТТР/1.1 405 Method Not Allowed Allow: GET, HEAD, POST, PUT

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

408 Request Timeout. Другой пример уточнения отразился в коде состояния 408 Request Timeout. Сервер может оказаться не готов все время ждать, когда клиент пришлет запрос, и может отключиться. Вместо того, чтобы закрывать соединение с неоднозначным кодом ошибки, сервер посылает более детализи- рованный код, указывающий, что он находится в состоянии таймаута.

410 Gone. Если ресурс отсутствует, НТТР/1.1 сервер вернет ответ 404 Not Found гакже как и серверы, поддерживающие НТТР/1.0. Однако если серверу известно, что этот ресурс был удален или если его новый адрес нельзя определить, чтобы указать его, можно использовать новый код ответа 410 Gone. Информация о том, что ресурс вряд ли появится нозже, известна благодаря внутренней конфигурационной информации доступной серверу. В этом случае клиент, в отличие от получения 404 Not Found, знает, что не следует повторять запрос, который вызвал ответ 410 Gone. При использовании метода DELETE, некоторые ресурсы могут быть удалены навсегда. Различие между 404 Not Found и 410 Gone похоже на различие между 301 Moved Permanently и 302 Found.

2.       Коды состояния согласования. Мы обсудим здесь два новых кода состояния относящихся к категории согласования.

413 Request Entity Too Large. Код ответа 413 Request Entity Too Large посылается, если сервер не может обработать сообщение-запрос слишком большого размера. Сервер может разрешить отправителю возобновить тог же запрос позже, если существует вероятность, что у пего появится возможность обработать содержимое большого размера. Заголовок Retry-After используется для указания времени, после которого клиент может повторить запрос. Этот код ответа особенно полезен в сочетании с механизмом Expect — клиент может послать заголовок Expect с размером содержимого запроса и если он получит ответ 100 Continue, то может посылать остальную часть запроса.

415 Unsupported Media Туре. Код ответа 415 Unsupported Media Туре используется тогда, когда содержимое запроса отправителя представлено в формате, который не поддерживается сервером для указанного запроса. Изменение метода запроса может изменить реакцию сервера. Предположим, запрос с методом PUT включает содержимое в формате, который не поддерживается сервером. Тог же формат может использоваться в запросе POST, возможно сервер сможет принять содержимое и передать его программе, которая это содержимое сможет обработать.

3.       Новые коды для других возможностей в НТТР/1.1. Мы обсудим два новых кода ответа в этой категории.

402 Payment Required. Код состояния 402 Payment Required был добавлен для электронной коммерции в Web. Тем не менее, за этим кодом не зарезервировано пикакой семаптики. Это просто «заполнитель» для будущего нри- менепия.

409 Conflict. Код состояния 409 Conflict был введеп в одном из первых проектов НТТР/1.0 для поддержки управления версиями, по формально до НТТР/1.1 в спецификацию не входил. Если два пользователя пытаются изменить ресурс с помощью метода PUT, Web-сервер может обнаружить эту ситуацию и нослать ответ 409 Conflict. Тело ответа включает указание на то, что может быть не так, если этог запрос будет выполнен. Ответ 409 Conflict посылается, если сервер имеет основания рассчитывать на то, что клиент может предпринять корректирующие действия и повторить запрос. Ответ может включать информацию, которая может быть использована агентом пользователя, чтобы принять соответствующие меры.

КОДЫ ОТВЕТОВ 5XX

Из двух новых кодов ответов класса 5xx ответ 504 Gateway Timeout уже рассматривался в контексте директив управления кэшами. Еще один повый код ответа этого класса — это 505 HTTP Version Not Supported. Это специфический код ошибки, указывающий, что номер версии протокола в сообщении-запросе не поддерживается сервером. Такое отсутствие поддержки может быть обусловлено чем-то очень простым, например, сервер может не воспринимать сообщения в формате того номера версии протокола, который использовал отправитель. Или паоборог, возМожно сервер не воспринимает семаптику и не отвечает требованиям, которые подразумевались отправителем. Данный ответ может указывать на другой протокол, поддерживаемый сервером, чтобы отправитель мог отправить соответствующий запрос.

Резюме

Спустя почти десять лет с момента своего появления протокол HTTP сформировался в наиболее популярный современный протокол прикладного уровня. Потоки данных, передаваемых в доступной измерениям части Internet, показывают, что три из четырех пакетов передаются по протоколу HTTP версий НТТР/1.0 или НТТР/1.1. По любой мерке это ошеломляющая статистика. Хотя с протоколом НТТР/1.0 были связапы некоторые проблемы, значительная часть трафика Internet продолжает передаваться по этому протоколу. Многие браузеры и серверы поддерживают НТТР/1.1, по большинство промежуточных компонентов продолжают поддерживать протокол НТТР/1.0. Это озпачаег, что лишь небольшая часть сквозпого трафика полностью осуществляется по протоколу НТТР/1.1. Один из доводов в пользу усовершенствования механизма промежуточных передач в НТТР/1.1 заключается в возможности, что усовершенствования протокола смогут использоваться между любыми двумя компонентами, реализующими НТТР/1.1.

В этой главе приведены логические обоснования перехода к НТТР/1.1 и, где это уместно, прослежепа эволюция идей, лежащих в основе этих изменений. Мы падеялись познакомить читателей с процессом разработки протоколов, который часто осуществлялся в непростых условиях. Сравнительное изложение элементов НТТР/1.0 и НТТР/1.1. должно помочь читателю оценить объем работы, проделанной в процессе эволюции протокола. Систематизация основных изменений должна помочь сосредоточиться на важпых аспектах протокола с практической точки зре- пия. Читатели должпы помнить, что хотя мы честпо пытались охватить большое число проблем, в области корректности изложения последнее слово остается за стандартами IETF. В следующей главе рассматривается взаимодействие протокола транспортного уровня с HTTP.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100