Интегрированные сети ISDN


UA – агент пользователя - часть 66


12.6 Неопределенность из-за множественных откликов

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

Ни метка объекта, ни значение времени жизни не могут определять порядок откликов, так как возможно, что более поздний отклик имеет срок годности, который истекает раньше. Однако, спецификация HTTP/1.1 требует передачи заголовка Date в каждом отклике, а значения Date должны быть кратны одной секунде.

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

Cache-Control: max-age=0

Чтобы заставить некоторые промежуточные кэши сверить свои копии непосредственно с исходным сервером, или

Cache-Control: no-cache

Чтобы заставить любые промежуточные кэши получит новые копии от исходного сервера.

Если значения Date равны, тогда клиент может использовать любой отклик (или может, если он особенно осторожен, затребовать новый отклик). Серверы не должны зависеть от возможности клиентов четкого выбора между откликами, сгенерированными в пределах одной и той же секунды, если их сроки пригодности перекрываются.

12.8 Модель проверки пригодности

Когда кэш имеет устаревшую запись, которую бы он хотел использовать в качестве отклика на запрос клиента, он сначала должен произвести сверку с базовым сервером (или возможно промежуточным кэшем, содержащим свежий отклик), чтобы убедиться, что кэшированная запись все еще применима. Мы это называем проверкой пригодности записи кэша ("validating"). Так как мы не хотим пересылки всей записи, если с ней все в порядке, и мы не хотим тратить лишнее время из-за RTT в случае, если запись более не пригодна, протокол HTTP/1.1 поддерживает использование условных методов.




Начало  Назад  Вперед