InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я рассказывал в статье "Межпланетная файловая система IPFS".
Прошло некоторое время от начала моих экспериментов с хостингом простых сайтов в IPFS. Запустил я свой IPFS клиент под Windows и у меня есть теперь что дополнить к предыдущей статье "Публикуем сайт в межпланетной файловой системе IPFS"
- Решение проблемы c utf-8 в консоли Windows XP.
- Своя страница 404
- Корректная загрузка сайта с разных URL
Перед стартом
Необходимо создать ярлык на ipfs.cmd файл в свойствах которого поменять шрифт на Lucida Console. Это даст возможность переключиться на UTF-8.
Запуск IPFS под Windows
Хочется видеть какие запросы приходят к нашему клиенту. Используем командный файл. Он настроит вывод консоли, переменные и при помощи findstr или grep отфильтрует вывод IPFS клиента.
Для Windows 7 и новее
Файл: ipfs.cmd
rem Переключаем на UTF-8 (>= Windows 7)
chcp 65001
rem Выключаем цветной лог который не работает в консоли Windows
SET IPFS_LOGGING_FMT=nocolor
rem |-D - включает режим DEBUG в котором в консоль выводится информация о работе клиента
rem |listening - покажет открытые порты
rem |namesys - покажет процесс разрешения домена
rem |path - покажет конечный путь куда обращается клиент
ipfs.exe daemon -D 2>&1|findstr "listening namesys path" 2>nul
pause
Для Windows XP
В Windows XP есть особенность что попытавшись переключить на utf-8 в командном файле выполнение сразу завершается. Методом проб и ошибок мне удалось переключить кодировку в командном файле.
Решение: start "utf-8" /B cmd /C chcp 65001
Нам понадобится Grep for Windows. Findstr вырубается при включенном UTF-8 от первой строки в которой присутсвуют символы кирилицы. Ну и отображает за место них точки.
Файл: ipfs.cmd
rem Переключаем на UTF-8 (Windows XP)
start "utf-8" /B cmd /C chcp 65001
rem Выключаем цветной лог который не работает в консоли Windows
SET IPFS_LOGGING_FMT=nocolor
rem |-D - включает режим DEBUG в котором в консоль выводится информация о работе клиента
rem |listening - покажет открытые порты
rem |namesys - покажет процесс разрешения домена
rem |path - покажет конечный путь куда обращается клиент
ipfs.exe daemon -D 2>&1|grep "listening\|namesys\|path" 2>nul
pause
404 Not Found (manifest.appcache)
В IPFS нет настраиваемой страницы 404. Мы её можем имитировать при помощи appcache.
Файл: manifest.appcache
CACHE MANIFEST
# 2017-03-29 v1.0
# Записываем в кеш 404.html
CACHE:
404.html
# Назначаем её ответом в случае получения 404 от сервера
FALLBACK:
/ 404.html
# Разрешаем всё остальное грузить с сервера
NETWORK:
*
При использовании appcache нельзя устанавливать заголовок Expiries для страниц на которых объявлен manifest.appcache и ресурсов указанных в манифесте в разделе CACHE. При обновлении файла manifest.appcache Firefox "обновляет" файлы указанные в манифесте из собственного кэша чем оставит старые файлы с обновлённым манифестом.
На страницах нельзя указывать в теге base <base href="https://домен/" />
который ведёт на другой домен. Firefox дополняет путь к файлу манифеста значением свойства href тега base и блокирует загрузку manifest.appcache если он на другом домене или протоколе (http -> https).
Другие нюансы: "Основные ловушки при использовании кэша в HTML5-приложениях"
URL Относительные пути к ресурсам
Внешние ресурсы страницы должны быть указаны относительными путями. Содержимое сайта в IPFS может быть загружено с множества разных url разной степени вложенности.
http://домен/страница.html
http://ipfs.io/ipns/домен/страница.html
http://ipfs.io/ipns/мультихеш_публичного_ключа/страница.html
http://ipfs.io/ipfs/мультихеш_каталога/страница.html
и даже так
http://ipfs.io/ipfs/мультихеш_файла
Для последнего случая лучше включать css и js в страницу. Либо включить скрипт который обработает данный случай и выставит правильные ссылки на ресурсы и страницы.
Также вместо "ipfs.io" или домена в адресе может быть:
localhost:8080
127.0.0.1:8080
[::1]:8080
и так далее.
В итоге у нас получится такая страница.
Файл: index.html
<!doctype html>
<!-- Используем относительный путь в manifest -->
<html manifest="manifest.appcache">
<head>
<meta charset="utf-8" />
<title>Мой сайт</title>
<script>
if (window.location.hash.substr(1,8) == "magnet:?"){
var magnet = document.location.hash.substr(9)
// Используем относительный путь в скриптах
setTimeout(function() {window.location.replace("magnet-converter/#magnet:?"+magnet);}, 0);
}
</script>
</head>
<body>
<!-- Используем относительные пути в href -->
<a href="magnet-converter/">magnet converter</a>
<a href="gravity/gravity.svg">gravity</a>
<a href="https://github.com/ivan386?tab=repositories">All projects</a>
<!-- Используем относительные пути в src -->
<img src="imgs/stars-static.svg" style="display: block; width: 100%" />
</body>
</html>
IPFS как зеркало
Не обязательно использовать IPFS клиент как HTTP-сервер. Можно использовать любой HTTP-сервер который будет отдавать содержимое сайта если у посетителя не установлен IPFS клиент. В IPFS можно загрузить зеркало этого сайта.
Заключение
Рассказал что вспомнил. Надеюсь это не мало. Есть идея по реализации дедупликации и ускорения классического интернета за счёт IPFS. Надеюсь рассказать об этом в будущих статьях с рабочими примерами.
Мои релизы клиента IPFS с исправлениями на GitHub:
- Совместимость с punycode.
- Etag для всех GET запросов.
- Правильное определение скрытых файлов в Windows.
alexeykuzmin0
Лично мне (и, думаю, я такой не один) было бы интереснее не «как?», а «зачем?». Какие проблемы (в т.ч. и потенциальные проблемы далекого будущего) это решает?
ivan386
IPFS решает те же проблемы что и Сеть доставки содержимого — проблемы доступности контента.
В будущем предполагается что между планетами будет медленная связь. IPFS за счёт распределения и дедупликации контента будет ускорять серфинг по сети. Также сеть действует как глобальный архив.