RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

13.13. Списки history

У пользовательских агентов часто есть механизмы хронологии, например, кнопки "Back" и списки предыстории, которые могут использоваться, чтобы восстановить изображение объекта, найденного ранее в сеансе.

Механизмы хронологии и кэши отличны. В определенной хронологии механизмы не ДОЛЖНЫ попытаться показать семантически прозрачному представлению текущего состояния ресурса. Скорее механизм хронологии предназначается, чтобы показать точно, что видел пользователь в то время, когда ресурс был найден.

По умолчанию, время expiration не применяется к механизмам хронологии.

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

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

Обратите внимание: Если механизмы списка предыстории излишне будут препятствовать тому, чтобы пользователи рассмотрели устарелые ресурсы, то это будет иметь тенденцию вынуждать сервисных авторов избежать использовать HTTP управления expiration и управления кэша, когда они иначе хотели бы к. Сервисные авторы могут счесть его важным, что пользователи не быть представленными сообщения об ошибках или предупреждающие сообщения, когда они используют навигационные управления (например, BACK), чтобы рассмотреть ранее выбранные ресурсы. Даже при том, что иногда такие ресурсы не должен к кэшируемому, или должны истечь быстро, рассмотрения пользовательского интерфейса могут вынудить сервисных авторов прибегнуть к другим средствам предотвращения кэширующего (например "once-only" URL), чтобы не перенести эффекты ненадлежащим образом функционирующих механизмов хронологии.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.