IPFS: кэширование неизменных выпусков

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

Мы не настраиваем сервер, CDN или Service Worker и не измеряем hit rate. Значения заголовков ниже являются объясняющим исходником. Конкретная политика зависит от выбранного шлюза и требований библиотеки.

Объект определён содержанием

Если URL однозначно относится к конкретному CID и сервер выдаёт правильные данные, содержание не должно меняться под тем же идентификатором. Это удобное основание для длительного хранения копии. При следующем чтении клиент может использовать уже проверенные байты.

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

CID манифеста и его SHA-256 имеют разные роли, как установлено раньше. После клиентской проверки конкретные сохранённые байты связаны с объявленным выпуском. Изменение текущей записи реестра не делает эти старые байты повреждёнными; меняется рекомендация версии.

Изменяемый указатель

IPNS, DNSLink или обычная страница курса могут указывать на текущий выпуск. Их ответ должен обновляться по собственной политике свежести. Долгий кэш «edition-1» мешает увидеть переход на «edition-2», хотя обе редакции по отдельности неизменны.

current-name ──короткая свежесть──→ выбранный корень
корневой CID ──неизменные данные─→ сохранённые файлы

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

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

HTTP-заголовки

Для собственного HTTP-ответа конкретного неизменного ресурса можно рассматривать длительный max-age и директиву immutable при соответствующем договоре. Но эти заголовки сообщает сервер; клиент должен понимать, относится ли URL действительно к неизменным данным.

Cache-Control: public, max-age=31536000, immutable

Листинг объясняет форму, а не применённую конфигурацию. Для личного статуса счёта такой ответ был бы неправильным: сумма и стадия оплаты изменяются, а данные могут относиться только к авторизованному читателю. Нельзя переносить кэширование учебного файла на серверную сессию.

ETag и другие валидаторы также не следует без проверки называть CID. Их смысл задаёт оператор HTTP. Даже если значение выглядит как хеш, оно может относиться к сжатому представлению, иной версии или внутренней процедуре. Клиентская проверка ожидаемых байтов остаётся самостоятельной.

Представления и сжатие

HTTP может передавать сжатую форму файла. Приложение должно определить, какие байты относятся к договору манифеста: исходный восстановленный файл или иной контейнер. Обычно файловая контрольная сумма касается исходной последовательности после предусмотренного декодирования, но правило задаётся явно.

Не сравниваем digest сжатого тела с SHA-256 несжатого HTML, считая несовпадение подменой. Сначала понимаем формат и обработку. В то же время ошибочная трансформация сервером может изменить итоговые байты, поэтому заголовки не оправдывают любое расхождение.

Для доверенного block-маршрута проверяются соответствующие блоки по формату. Для обычной файловой выдачи — восстановленная последовательность. Оба маршрута могут использовать транспортное кэширование, не меняя основания содержания.

Ошибки в кэше

Ответ отсутствующего файла не должен на годы занимать место правильного результата из-за ошибочного долгого правила. Политика ошибок и положительных объектов различается. После появления реплики прежний сетевой тайм-аут не является неизменным фактом о CID.

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

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

Сохранить ответ или запросить подтверждение

Директива no-cache не означает безусловный запрет хранить HTTP-ответ. Она требует предусмотренной повторной проверки перед соответствующим использованием сохранённой копии. no-store задаёт другую политику хранения. Поэтому выбор заголовка для изменяемой страницы «текущая версия» нельзя делать только по бытовому значению слова cache. Библиотека отдельно определяет допустимое сохранение указателя и условия его актуализации.

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

В браузере сервис-воркер может также хранить собственную копию для офлайн-режима. Его ключи должны различать редакции и необходимые представления. Если ключом станет только номер курса, вторая редакция способна незаметно заменить первую, хотя пользователь сохранил конкретный выпуск. Для нашей модели ключ включает идентичность выпуска, а изменяемая рекомендация «текущий» хранится отдельно. Обновление одного слоя не должно переписывать смысл другого.

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

Офлайн и очистка

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

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

Документация директив доступна в MDN Cache-Control, а выдача конкретных объектов — в Path Gateway Specification. После урока библиотека может быстро отдавать проверенный выпуск и отдельно обновлять текущую рекомендацию, сохраняя честные статусы локального хранения.

Оглавление серии