Механизм Expect/Continue

Если HTTP-сервер не может обрабатывать запросы большого объема, было бы полезно для клиента знать об этом до того, как посылается запрос. Клиент может извлечь выгоду, зная, что его ожидания соответствуют действительности до отправки запросов на большие ресурсы. Рассмотрим пример обработки Web-сервером больших форм с помощью методов PUT или POST. Хотя протокол не накладывает ограничений на размер тела содержимого, у Web-серверов есть свой собственный внутренний предел, основанный на ограничениях, связанных с обработкой и хранением. Однако к тому времени, когда агент пользователя узнает, что сервер отклонит его запрос, будет уже поздно. Пользователь, возможно, затратил значительные усилия и время на заполнение формы. У агентов пользователя могут быть средства для оценки размеров заполненных форм. Кроме того, раз уж запрос был послан, напрасно загружалась сеть. Механизм, посредством которого агент пользователя может узнать о возможных ограничениях сервера до отправки большого запроса, полезен для клиента и сокращает бесполезный трафик.

Механизм Expect обеспечивает именно такое решение. Оп позволяет клиенту узнать, способеп ли сервер удовлетворить ожидания клиента в том, что касается конкретного ресурса. Если сервер готов соответствовать заявленным ожиданиям и обработать данный запрос, оп может сообщить об этом с помощью ответа 100 Continue. Сервер, неспособный обработать такой запрос, может послать соответствующий код ответа, основанный на коикретпой причине неспособности обработать данный запрос. Если запрос имеет слишком большой объем, сервер может послать 413 Request Entity Too Large. Если данному клиенту не было разрешено сделать такой запрос, сервер может послать 403 Forbidden. Если сервер получает неизвестную лексему в Expect или если ему известно, что сервер, расположенный выше в цепочке на пути к исходному серверу, не сможет работать с механизмом Expect, оп посылает ответ в виде кода состояния 417 Expectation Failed. Ответ посылается до того, как на исходный сервер реалыю посылает тело запроса.

Например, рассмотрим следующий запрос, носланный с заголовком Expect. Клиент плапируег послать тело запроса размером 23248 байтов.

POST /foo/bar НТТР/1.1 Content-Length: 23248 Expect: 100-Continue

Сервер может ответить гак:

НТТР/1.1 100 Continue

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

НТТР/1.1 417 Expectation Failed

Клиенты могут включать дополнительные значения в заголовок Expect. Например, клиент может иослать аутептификационпую информацию пользователя, инициировавшего этот запрос. Если сервер принимает эту информацию, он обычно посылает ответ 100 Continue, и клиент может отправлять тело сообщения-запроса в следующем виде:

P0ST /secure.txt НТТР/1.1 Host: www.topsecret.org Authorization: Basic ZGufaWP6J29atWU= Expect: 100-Continue

Если сервер возвращает промежуточный код ответа

НТТР/1.1 100 Continue

клиент может продолжать запрос. Если вместо этого сервер возвращает

НТТР/1.1 401 Authorization Failed

оставшаяся часть запроса не передается. Клиенту придется или посылать новые данные для авторизации, или отказаться от запроса.

Изучение того, как протокол применяется на практике, — это один из способов дальнейшего развития протокола его разработчиками. Полезность некоторых свойств протокола может оставаться неясной, поэтому реальный учет данных о рап- niix версиях протокола может помочь его совершенствованию. К сожалепию, уже существует несколько несовместимых версий так называемых НТТР/1.1-реализаций компонентов, что вынуждает спецификацию протокола относиться более терпимо к операциям с механизмом Expect. Может случиться так, что клиент, который посылает заголовок Expect:100-Continue, будет ждать ответа 417 Expectation Failed или 100 Continue неопределенное время. Чтобы исключить такую ситуацию, клиент должен умегь приостанавливать свою работу на определенное время, а после этого посылать тело запроса (фактическая продолжительность таймаута может зависеть от реализации клиента). Протокол запрещает клиенту ждать неопределенное время, хотя и не определяет продолжительность таймаута. Поэтому клиент использует для ожидания не детермииироваииый, а случайный период времени.

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

Хотя механизм Expect был предложен для обработки запросов большого объема, связанных с методами PUT и POST, он может использоваться в будущем и для других расширений. Серверы, которые пока еще не воспринимают новых расширений, обязаны возвращать код состояния 417 Expectation Failed. Возможным расширением механизма Expect является совершенствование схемы согласований НТТР/1.1.

Интересно отметить, что заголовок Expect был введеи не как управляемый клиентом механизм согласования ожидаемого результата, а для решепия проблемы, связанной с ответом 100 Continue. Ответ 100 Continue был предложен почти за два года до введения заголовка Expect. Ответ 100 Continue был введен, чтобы сервер мог посылать промежуточный код ответа, если он был намерен продолжать принимать входные данные от клиента. Клиент имеет разумное основание не посылать содержимое своего запроса до тех пор, пока не убедится, что Web-cepвep примет его запрос. Если Web-cepвep не памерен продолжать чтение входных данных, он может послать сообщение об ошибке. Например, если запрос клиента POST, включает заголовок Content-Length, и сервер знает, что не сможет обработать запрос такого размера, оп может вернуть код ошибки. Если сервер может обработать такой запрос, он может послать ответ 100 Continue. Такое решение требует, чтобы клиент сделал паузу, прежде чем передавать содержимое запроса. Однако отправитель может прождать очень долго, прежде чем выяснится, что сервер не собирается посылать ии 100 Continue, ни сообщение об ошибке. Первым предложением было ввести пятисекундный таймаут, по скоро стало яспо, что произвольно выбранное время ожидания клиента не является удовлетворительным решением во всех случаях. Еще важнее было то, чтобы клиенты, использующие НТТР/1.0, не могли воспринимать ответ 100 Continue, так как оп был определен только в НТТР/1.1.

Чтобы избежать такого рода проблем, был добавлен заголовок Expect, с таким расчетом, чтобы ответ 100 Continue был возможен только в том случае, если в запросе присутствовал заголовок Expect. Не все клиенты должпы ждагь ответ 100 Continue. Окончательная формулировка правил для клиентов и серверов в НТТР/1.1 содержит следующее: клиент должен послать заголовок Expect, если оп намерен ждать ответ 100 Continue, а сервер должен вернуть или 100 Continue, или заключительное сообщение об ошибке. Если клиент, отправивший заголовок Expect, так и не получил от Web-сервера ответ 100 Continue, оп не должен ждать неопределенно долго, а может продолжать свою работу и отправить содержимое запроса.

Источник: 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