Кратко

  • В режиме RESPMOD срок действия адаптированного объекта происхождения не может быть позже срока исходного объекта, хотя сервис вправе сократить его.
  • Свежесть источника, актуальность правил ISTag, возраст OPTIONS, увиденные Preview-байты и результат у получателя — разные доказательства; один cache hit их не объединяет.

Преобразованная копия ещё числилась свежей. Исходный ответ уже истёк. Кэш продолжал выдавать производный объект, как будто адаптация получила право продлить заявление источника.

Именно такого переноса полномочий правило RFC 3507 не допускает. Сервис может сделать производный объект менее долговечным, но не может одним преобразованием дать ему более поздний срок, чем был у основания.

RFC 3507 опубликован в апреле 2003 года как Informational RFC, фиксировавший уже применявшийся протокол. ICAP — отдельный протокол поверх TCP, который инкапсулирует части HTTP; это не HTTP и не протокол поверх HTTP. Примечание IESG также отделяет механизм от архитектурных и политических вопросов OPES, поставленных в RFC 3238.

Производный объект наследует предел источника

В RESPMOD клиент передаёт сервису инкапсулированный HTTP-ответ. Сервис может вернуть изменённый ответ или, при выполнении условий, указать, что адаптация не возвращается.

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

Сервис может назначить более раннее истечение. Например, правило безопасности или оперативная политика могут требовать короткой жизни производной копии. Но более поздняя дата требует новой валидации источника, а не старого факта адаптации.

Доказательство должно хранить исходные директивы кэша, время получения, вычисленное истечение, изменения сервиса и конечные директивы. Сохранение только итоговой даты уничтожает происхождение ограничения.

ISTag добавляет вторую границу свежести

Каждый ответ ICAP должен нести ISTag. Метка может представлять программное обеспечение, конфигурацию или данные решений сервиса. При изменении состояния, которое делает старые результаты непригодными, новая метка позволяет клиенту инвалидировать связанный кэш.

Область метки шире ETag одной HTTP-репрезентации: она может относиться ко многим объектам, созданным одним URI сервиса. Поэтому результат может быть свежим по HTTP, но устаревшим по эпохе адаптации.

Метка не является криптографической аттестацией и не доказывает синхронность кластера. Её надо связывать с манифестом правил, узлами, временем активации и фактической инвалидизацией.

OPTIONS живёт по третьим часам

OPTIONS сообщает методы, размер Preview, обработку передач, Allow, предел соединений, срок опций и текущий ISTag. Ответ имеет собственное время жизни.

Значит, у повторного использования как минимум три часов: возраст возможностей OPTIONS, HTTP-свежесть адаптированного объекта и действительность эпохи сервиса. Они могут истекать в разном порядке.

Запрос, основанный на просроченном OPTIONS, использует старую договорённость о Preview или 204. Объект с действующей HTTP-датой может принадлежать старой метке. Новый tag не продлевает исходный ответ. «Кэш свеж» без названия часов ничего не доказывает.

Preview ограничивает увиденное до решения

В Preview клиент отправляет все инкапсулированные заголовки и не больше объявленного числа байтов тела. Затем временно завершает поток chunks и ждёт.

Сервис может вернуть адаптацию, 204 No Content или 100 Continue, если осталось тело. Точка остановки способна находиться внутри тела, поэтому решение надо связывать с запрошенной и фактической длиной, offsets, границами chunks и первым невидимым байтом.

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

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

ieof показывает, когда Preview содержала конец

Если источник завершился во время формирования Preview, последний chunk несёт расширение ieof. Сервис знает, что фактический конец тела уже получен, и не вправе просить продолжение через 100 Continue.

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

Отсутствие ieof не гарантирует последующих данных: источник может оборваться позже. Нельзя превращать приглашение продолжить в доказательство полного объекта.

204 сохраняет оригинал, а не выносит вердикт

Во время Preview 204 No Content разрешает клиенту продолжить так, будто полное сообщение вернулось неизменным. Экономия возможна, потому что клиент сохранил Preview и располагает остальной частью оригинала.

Вне Preview клиент может объявить Allow: 204 и принять ответственность за реконструкцию. Без такого разрешения сервис обязан вернуть полное идентичное сообщение, даже если не меняет его.

Статус описывает владение байтами и расходы памяти. Он не означает «безопасно», «подлинно» или «разрешено». Сервис может не хотеть или не уметь изменить объект.

Для кэша нужен хеш реконструированного оригинала и доказательство того, какие его директивы свежести сохранились.

Встроенный HTTP-статус имеет собственного автора

REQMOD способен вернуть изменённый запрос, HTTP-ошибку, разрешённый 204 или ICAP-ошибку. HTTP-ошибка могла быть создана адаптером до обращения к origin.

RESPMOD начинает с ответа origin, но конечная репрезентация может быть создана сервисом. Следующий получатель ещё может её отвергнуть или интерпретировать иначе.

Нужны хеши до и после, правило, идентичность сервиса, ISTag и итог следующего хопа. Последний HTTP-код без автора стирает причинность.

100 Continue покупает больше входных данных

Если тело не закончилось в Preview, сервис ICAP может вернуть 100 Continue. Клиент отправляет остаток с первого chunk после окна.

Это не одобрение origin и не конечный результат адаптации. После полного ввода всё ещё возможны изменение, 204 или ошибка; затем отдельно решают HTTP-узел и приложение.

Телеметрия должна отличать ICAP 100 от любого HTTP 100, указывать соединение, URI и первый байт после Preview.

Offsets описывают контейнер, но не смысл

Заголовок Encapsulated задаёт offsets заголовков и тел запроса или ответа, OPTIONS-тела либо null-body. Он позволяет разобрать составное сообщение, но не валидирует всю HTTP-семантику.

Chunk framing, конец Preview, ieof, финальный ICAP-статус и встроенный HTTP-статус принадлежат разным слоям. Сохранение только пересобранного HTTP может уничтожить границу наблюдения.

Полномочие адаптации находится вне даты кэша

RFC 3238 и последующие документы OPES обсуждают согласие, уведомление, приватность, URI, правила, домены доверия и трассировку. Они не делают каждое развёртывание ICAP системой OPES и не дают кэшированной копии политического мандата.

Диспетчер должен показать, чьё правило выбрало сервис, в каком доверительном домене и с каким уведомлением. Техническая свежесть и право преобразования связаны, но не взаимозаменяемы.

Цепочка для безопасного cache hit

Сначала сохраняются исходные HTTP-байты, роль и точка наблюдения, директивы кэша и срок. Затем ICAP URI, метод, стороны, OPTIONS, его истечение и ISTag, а также проверенные offsets.

Фиксируются Preview, фактические байты, ieof, чтение источника, буфер, промежуточный или конечный статус. Для изменения сохраняются до, после и правило; для 204 — точная реконструкция.

Запись кэша включает ключ, исходный предел, сокращённый предел, tag и решение об инвалидизации. Наконец проверяются следующий HTTP-хоп, доставка, авторизация и аутентифицированный результат приложения.

Граница доказательства

Статья не указывает на современный продукт, прокси, сканер или инцидент. Она не утверждает, что кэширование адаптированных объектов ошибочно. Она сохраняет предел полномочий источника и сервиса.

Она также не повторяет существующую историю HTTP 100 Continue, посвящённую разрешению тратить тело запроса на HTTP-границе. Здесь предмет — время жизни производного объекта и эпоха сервиса.

Принципы Heng Lu о минимальной начальной спецификации и приоритете running code раскрыты как редакционная оптика. Они поддерживают тонкий общий контракт и проверку исполненного пути, но не измеряют внедрение ICAP.

Вывод узок: преобразование может сократить жизнь объекта, но не продлить слово источника. Для каждого cache hit это надо уметь доказать.

Sources