IPFS: HTTP-шлюз и собственная проверка
Обычный браузер умеет получить файл по HTTP, а шлюз преобразует путь с CID в такой ответ. Это удобный способ открыть выпуск библиотеки без специального клиентского обмена. В уроке разберём путь запроса и отделим доверие к ответу сервера от независимой проверки содержания.
Мы не обращаемся к публичному шлюзу с новым выпуском и не проверяем скорость выдачи. Значение ROOT_CID остаётся меткой. Сетевой профиль будет выбран отдельно при разрешённом исполнении.
Path-шлюз
Типовая форма пути:
https://gateway.example/ipfs/ROOT_CID/lessons/01.htmlДомен указывает место HTTP-выдачи. CID указывает ожидаемый корень, а последующий путь — файл внутри структуры. Если заменить домен на другой совместимый шлюз, цель содержания может сохраняться. Но ответ всё равно проходит через выбранного оператора.
Шлюз может получать отсутствующие данные либо обслуживать только доступный ему набор в своей конфигурации. Не каждый endpoint обязан искать любые блоки в публичной сети. Поэтому ошибка получения может относиться к режиму или доступности, а не к неправильному CID.
URL также содержит браузерный origin. Для активного сайта это существенное свойство: JavaScript, cookies и хранилища регулируются origin, а не семантикой корня IPFS. Следующий урок подробно разберёт поддомены и изоляцию.
Что проверяет браузер
Обычный браузер доверяет защищённому HTTP-соединению и выбранному серверу в привычной модели. Наличие CID в URL само по себе не заставляет его разобрать DAG и сверить каждый блок. Поэтому надпись «IPFS» на адресе не является доказательством клиентской криптографической проверки.
Доверенное приложение может независимо получить байты манифеста, вычислить согласованный SHA-256 и сопоставить с CourseCatalog. Тогда сервер выдачи не может незаметно изменить этот проверяемый документ без обнаружения, если начальное приложение и канал объявления защищены.
Для отдельных файлов манифест содержит контрольные суммы. Читатель проверяет восстановленные байты по этому объявлению. Другой путь — получать блоковые ответы и проверять DAG средствами клиента. Это разные процедуры, и интерфейс должен сообщать, какая действительно выполнена.
Ошибки выдачи
HTTP 200 с HTML-страницей ошибки не является правильным уроком. Адаптер должен проверять ожидаемый статус, формат и контрольные значения. Заголовок Content-Type полезен, но не доказывает содержимое: он также является сообщением сервера.
Если вместо манифеста получен текущий HTML сайта, разбор JSON может завершиться ошибкой. Но надёжнее сначала сверить точные байты и предел размера. Это даёт предметную диагностику, а не попытку исправить чужой ответ под ожидаемую схему.
| Причина | Состояние клиента |
|---|---|
| Шлюз недоступен | Получение пока неизвестно/не завершено |
| Путь отсутствует | Нет нужного файла в разрешённой структуре |
| Байты не соответствуют объявлению | Проверка содержания не прошла |
| Схема не поддерживается | Подлинный документ не может быть обработан этим клиентом |
Эти состояния не объединяются в одну ошибку «блокчейн не работает». Они относятся к обычной сети, файловой структуре и проверке приложения.
Выбор резервного места
Если основной шлюз недоступен, можно попробовать другой разрешённый источник того же CID. Не меняем ожидаемый идентификатор на «похожий актуальный файл», иначе восстановительная выдача разрушит договор версии.
Браузер раскрывает новому оператору запрос и возможные метаданные. Поэтому автоматический обход большого списка сторонних шлюзов имеет последствия приватности и нагрузки. Библиотека выбирает ограниченный набор и объясняет переключение.
Для серверного прокси не принимаем произвольный hostname из параметра пользователя. Источники задаются конфигурацией, чтобы запрос к IPFS не превратился в доступ к внутренним службам. CID и путь также проходят безопасный разбор и пределы размера.
Кэш и заголовки
Неизменный путь конкретного CID подходит для длительного кэширования при корректной выдаче. Изменяемое имя требует иной свежести. Но кэшированный неправильный ответ может сохраняться, поэтому проверка по доверенному объявлению остаётся полезной.
Сервис должен корректно обрабатывать частичные запросы и типы файлов, если они требуются. Для небольшого манифеста удобно получить полный объект. Для крупного видео режим выдачи может быть другим, однако частичная доступность не равна полноте архива.
Скачивание файла отдельно от исполнения в браузере иногда уменьшает риск активного содержимого. Политика приложения определяет, какие типы открываются встроенно и какие выдаются как вложение. Правильный CID не делает любое расширение безопасным HTML.
Успешный HTTP-ответ с неправильным телом
Шлюз может вернуть статус 200 и HTML своей страницы ошибки вместо ожидаемого манифеста. Если приложение ориентируется только на успешный статус, оно ошибочно объявит выпуск загруженным. Поэтому результат оценивается последовательно: ответ получен, формат допустим, размер укладывается в предел, байты соответствуют ожидаемому обязательству, схема манифеста поддержана. Успех одной стадии не заменяет остальные.
Не стоит разбирать любой ответ как JSON и показывать исключение пользователю без контекста. Несовпадение типа или контрольного значения относится к выдаче либо данным, а временный сетевой отказ — к получению. Библиотека сохраняет источник и ожидаемую цель, чтобы оператор видел, какая копия ответила неожиданно. Одна неверная выдача не меняет доверенный отпечаток: клиент не записывает новое значение из ответа шлюза поверх объявленного реестром.
Для серверного посредника дополнительно важно, откуда берётся адрес. Пользователь не получает возможность передать произвольный URL, который сервер затем откроет от своего имени. Маршрут использует разрешённые источники и корректно разобранный идентификатор, ограничивает время, размер и перенаправления по собственной политике. Эти ограничения защищают границу веб-приложения независимо от того, что запрашиваемое содержание адресуется CID.
Переход к резервному источнику сохраняет тот же ожидаемый объект. Если один шлюз недоступен, а второй предлагает другую редакцию, это не резервная выдача прежнего выпуска. Клиент либо получает соответствующие байты, либо показывает объяснимый отказ. Для пользователя можно предложить отдельно открыть текущую версию, но это уже новый выбор. Такая модель делает шлюз заменяемым транспортом: источники меняются, а идентичность учебного материала и основания доверия остаются установленными заранее.
Результат маршрута
В досье сохраняем разрешённые шлюзы, форму пути, критерии ответа и способ независимой проверки. Пока получений не было, статус — подготовленный маршрут. Не называем эту конфигурацию измеренно быстрой или проверенной на всех браузерах.
Модели выдачи описаны в документации шлюзов и HTTP Gateway. После урока адрес с CID становится понятным сочетанием объекта и места выдачи. Следующий шаг — изоляция активных выпусков по origin, без которой удобный общий шлюз способен смешать браузерные полномочия разных материалов.