Протокол HTTP 1.1 - Коммуникации и связь - Скачать бесплатно
различным указателями достоверности, то он должен
использовать тот из них, у которого заголовок Date более свеж. Такая
ситуация может вознкнуть либо когда кэш объединяет ответы других кэшей,
либо когда клиент запросил перезагрузку или перепроверку достоверности
очевидно свежего вхождения кэша.
13.2.6 Устранение противоречий между несколькими ответами.
В силу того, что клиент может получать ответы многими путями, возможна
ситуация, когда кеш получает один поток ответов через один набор кэшей, а
другой поток ответов через другой набор кэшей. В таком случае клиент может
получать ответы в порядке, отличном от того, в котором их посылал
первоначальный сервер. Мы хотели бы, чтобы клиент использовал наиболее
свежий ответ, даже если ранее полученные ответы все еще очевидно свежи.
Ни метка объекта ни значение устаревания не можгут быть использованы
для упорядочения ответов, так как, возможно, более поздний ответ
преднамеренно несет более раннее время устаревания. Однако, спецификация
HTTP/1.1 требует передачи заголовков Date в каждом ответе, и значения Date
упорядочивают степень детализации до одной секунды.
Когда клиент пытается повторно проверить достоверность вхождения кэша,
и ответ, который он получает, содержит заголовок Date, который старше, чем
у существующего вхождения, то клиенту следует повторить запрос без
изменений, но включить
Cache-Control: max-age=0
чтобы вынудить промежуточные кэши проверить достоверность их копий
непосредственно первоначальным сервером, или
Cache-Control: no-cache
чтобы вынудить промежуточные кэши получить новую копию с
первоначального сервера.
Если значения Date равны, то клиент может использовать любой ответ
(или может, если он чрезвычайно предусмотрительный, запросить новый ответ).
Серверы не должны полагаться на то, что клиенты способны выбрать между
ответами, порожденными в течение одной секунды, если их времена устаревания
накладываются.
13.3 Модель проверки достоверности (validation model).
Если кэш имеет просроченное вхождение, которое он хотел бы
использовать в качестве ответа на запрос клиента, он сначала должен
свериться с первоначальным сервером (или с промежуточным кэшем, обладающим
свежим ответом) чтобы узнать, является ли вхождение кэша все еще пригодным
для использования. Мы называем это "проверкой достоверности" вхождения
кэша. Так как мы не хотим оплачивать излишнюю передачу полного ответа,
когда кэшируемый нас устраивает, и так как мы не хотим оплачивать лишнюю
передачу ответа туда и обратно, когда кэшируемое вхождение нас не
устраивает, протокол HTTP/1.1 поддерживает использование условных методов.
Ключевые возможности протокола для обеспечения условных методов - те,
что имеют отношение к "указателям достоверности (validators) кэша". Когда
первоначальный сервер генерирует полный ответ, он присоединяет к нему
некоторый указатель достоверности (validator), который сохраняется во
вхождении кэша. Когда клиент (агент пользователя или кэш прокси-сервера)
делает условный запрос на ресурс, для которого он имеет вхождение кэша, он
включает связанный указатель достоверности (validator) в запрос.
Затем сервер проверяет полученный указатель достоверности (validator)
на соответствие текущему указателю достоверности (validator) объекта, и,
если он соответствует, то сервер посылает ответ со специальным кодом
состояния (обычно 304 (не модифицирован), не содержащий тела объекта. В
противном случае, он возвращает полный ответ (включая тело объекта). Таким
образом, мы избегаем передачи полного ответа в случае соответствия
указателя достоверности (validator), и избегаем дополнительной передачи
туда-обратно в случае несоответствия.
В HTTP/1.1, условный запрос выглядит точно также, как нормальный
запрос того же ресурса, за исключением того, что он содержит специальный
заголовок (который включает указатель достоверности), который неявно
превращает метод (обычно, GET) в условный.
Протокол содержит как положительные, так и отрицательные условия на
указатели достоверности. То есть возможно запросить как метод, который
будет выполнен только в случае соответствия указателя достоверности, так и
метод, который будет выполнен только в случае несоответствия указателя
достоверности.
Ответ, который не содержит указателя достоверности, все же может
кэшироваться и обслуживаться из кэша пока не устареет, если это явно не
запрещено директивой Cache-Control. Однако, кэш не может производить
условный поиск, если он не имеет указателя достоверности объекта, что
означает, что ответ не будет регенерирован после того, как устареет.
Библиографический список
|Номер |Название |Авторы |Дата |Статус |Примечания |
|RFC | | | | | |
|822 |STANDARD FOR THE |David H. |August 13,|Proposed |Obsoletes: |
| |FORMAT OF ARPA |Crocker |1982 |Standard |RFC #733 |
| |INTERNET TEXT | | | | |
| |MESSAGES | | | | |
|850 |Standard for |RFC team |June 1983 |Information| |
| |Interchange of USENET| | |al | |
| |Messages | | | | |
|1036 |Standard for |M. |December |Proposed |Obsoletes: |
| |Interchange of USENET|Horton, |1987 |Standard |RFC-850 |
| |Messages |R. Adams | | | |
|1123 |Requirements for |Robert |October |Proposed | |
| |Internet Hosts -- |Braden |1989 |Standard | |
| |Application and | | | | |
| |Support | | | | |
|1738 |Uniform Resource |Tim |December |Proposed | |
| |Locators (URL) |Berners-L|1994 |Standard | |
| | |ee, | | | |
| | |Larry | | | |
| | |Masinter,| | | |
| | | | | | |
| | |Mark | | | |
| | |McCahill | | | |
|1766 |Tags for the |H. |March 1995|Standards | |
| |Identification of |Alvestran| |Track | |
| |Languages |d | | | |
|1808 |Relative Uniform |Roy T. |June 1995 |Proposed | |
| |Resource Locators |Fielding | |Standard | |
|1867 |Form-based File |E. Nebel,|November |Experimenta| |
| |Upload in HTML |L. |1995 |l | |
| | |Masinter | | | |
|1900 |Renumbering Needs |Brian E. |February |Information| |
| |Work |Carpenter|1996 |al | |
| | |, Yakov | | | |
| | |Rekhter | | | |
|1945 |Hypertext Transfer |T. |May 1996 |Information| |
| |Protocol -- HTTP/1.0 |Berners-L| |al | |
| | |ee, R. | | | |
| | |Fielding | | | |
| | |, H. | | | |
| | |Frystyk | | | |
|1950 |ZLIB Compressed Data |P. |May 1996 |Information| |
| |Format Specification |Deutsch, | |al | |
| |version 3.3 |J-L. | | | |
| | |Gailly | | | |
|1952 |GZIP file format |P. |May 1996 |Information| |
| |specification version|Deutsch | |al | |
| |4.3 | | | | |
|2048 |Multipurpose Internet|N. Freed,|November |Best |Obsoletes: |
| |Mail Extensions |J. |1996 |Current |1521, 1522, |
| |(MIME) Part Four: |Klensin, | |Practice |1590 |
| |Registration |J. Postel| | | |
| |Procedures | | | | |
|2068 |Hypertext Transfer |R. |January |Standards | |
| |Protocol -- HTTP/1.1 |Fielding,|1997 |Track | |
| | | | | | |
| | |J. | | | |
| | |Gettys, | | | |
| | |J. Mogul,| | | |
| | |H. | | | |
| | |Frystyk, | | | |
| | |T. | | | |
| | |Berners-L| | | |
| | |ee | | | |
|2069 |An Extension to HTTP |J. |January |Standards | |
| |: Digest Access |Franks, |1997 |Track | |
| |Authentication |P. | | | |
| | |Hallam-Ba| | | |
| | |ker, J. | | | |
| | |Hostetler| | | |
| | |, P. | | | |
| | |Leach, A.| | | |
| | |Luotonen,| | | |
| | |E. Sink, | | | |
| | |L. | | | |
| | |Stewart | | | |
-----------------------
[pic]
[pic]
[pic]
|
