💾 Archived View for sysrq.in › ru › article › gemini-docs › best-practices.gmi captured on 2024-08-24 at 23:46:24. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Этот документ описывает различные договорённости и полезные советы для реализации и использования протокола Gemini. Пусть они и не описаны в спецификации протокола, но придерживаться их будет хорошей идеей. Если вы пишете программное обеспечение для Gemini или создаёте капсулу, то стоит следовать этим советам (если нет веской причины не делать этого).
Gemini-серверы должны информировать клиентов о MIME-типе файлов, которые они передают. Самый распространённый способ выяснить MIME-тип файла на сервере - это посмотреть на его расширение. Эти соответствия в большинстве случаев стандартизированы (и в *nix-системах обычно присутствует очень длинный файл /etc/mime.types с их перечислением), но то, как серверы должны распознавать определённые в спецификации файлы text/gemini, остаётся под вопросом.
На данный момент Gemini-серверы используют для этой цели расширения .gmi и .gemini, и новым серверам настоятельно рекомендуется поддерживать один или оба варианта вместо того, чтобы изобретать новый.
Следуя принятым для веб-серверов соглашениям, если принятый запрос указывает на директорию в файловой системе сервера, то сервер должен передавать расположенный в ней файл index.gmi или index.gemini, если таковой существует.
Gemini-серверы не информируют клиентов о размере файлов, которые они передают, поэтому сложно обнаружить преждевременный разрыв соединения из-за ошибки на сервере. Риск того, что это может произойти, увеличивается с размером файла.
Gemini также не поддерживает сжатие больших файлов и сверку контрольных сумм для обнаружения "битых" файлов, вероятность появления которых тоже растёт с размером файла.
Из-за перечисленных выше причин Gemini так себе подходит для передачи "очень больших" файлов. От скорости и надёжности подключения к интернету, а также терпения пользователя в некоторой степени зависит то, какие файлы считать "очень большими". Практика показывает, что файлы размером больше 100 МБ следует передавать каким-нибудь другим способом.
И конечно, раз Gemini поддерживает ссылаться на онлайн-контент по любому поддерживающему URL протоколу, можно внутри Gemini-документа вставить ссылку на большой файл, который раздаётся по HTTPS, BitTorrent, IPFS или ещё чему угодно.
Gemini поддерживает любую кодировку через параметр "charset" MIME-типов text/*. Это позволяет передавать "древний" текстовый контент в странных и непонятых региональных кодировках.
Для нового контента, пожалуйста, Христа ради, просто используйте UTF-8. Спецификация Gemini обязывает клиенты уметь обрабатывать текст в кодировке UTF-8. Поддержка любой другой кодировки остаётся за клиентом и не гарантирована. Передача контента в кодировке UTF-8 увеличивает его доступность, а также увеличивает полезность простых клиентов, которые поддерживают только UTF-8.
Перенаправления были включены в Gemini в первую очередь с целью позволить реструктуризацию сайтов или переезд сайтов на другой сервер, не ломая уже имеющиеся ссылки. Большое и взаимосвязанное пространство из множества документов без такой возможности неизбежно становится "сломанным".
Однако перенаправления, вообще говоря, штука та ещё. Они снижают прозрачность протокола и делают сложнее принятие информированного решения о том, на какие ссылки перейти, а ещё они могут передавать информацию об онлайн-активности пользователей третьим лицам. В Gemini они не настолько плохи, как в HTTP (спасибо отсутствию куки, referer-заголовков и так далее), но они остаются в лучшем случаем неизбежным злом.
Поэтому, пожалуйста, воздерживайтесь от использования перенаправлений как попало! Такие вещи, как сервисы для сокращения URL, в большинстве случаев не имеют права на существование. В общем случае, хорошо и крепко подумайте перед использованием перенаправлений для любой цели, кроме предотвращения появления неработающих ссылок.
Клиенты могут спрашивать пользователей, следовать перенаправлению или нет, или делать это автоматически. Если вы пишете клиент, который автоматически следует перенаправлениям, имейте в виду то, что будет здесь сказано.
Неправильно настроенные или вредоносные Gemini-серверы могут отвечать перенаправлениями таким образом, что клиент, который слепо им следует, будет пойман в бесконечный цикл или будет вынужден совершить длинную цепочку перенаправлений. Надёжные клиенты должны распознавать эти состояния и действовать соответствующим образом. Простейший способ реализовать это - отказываться следовать более чем N перенаправлениям подряд. Рекомендуется, чтобы N было не больше, чем 5. Это соответствует оригинальным рекомендациям для HTTP (смотрите RFC-2068).
Перенаправления на другие протоколы (например, из Gemini на что-нибудь ещё, вроде Gopher) использовать в Gemini возможно, но строго не рекомендуется, однако неправильно настроенные или вредоносные серверы могут отвечать такими перенаправлениями, так что хорошо написанные клиенты должны быть готовы вычислять их и действовать соответственно.
Настоятельно рекомендуется, чтобы даже те клиенты, которые обычно следуют перенаправлениям автоматически, уведомляли пользователя и спрашивали явного подтверждения, когда сервер отвечает перенаправлением на протокол, использующий незащищённое соединение (такой как HTTP или Gopher), если клиент таковые поддерживает. Это избавляет от незапланированной передачи информации открытым текстом.
TLS версии 1.2 был разрешён для использования в Gemini, несмотря на то, что TLS 1.3 значительно проще и избавлен от многих небезопасных криптографических примитивов. Но только OpenSSL сейчас имеет хорошую поддержку TLS 1.3, поэтому требование TLS 1.3 и выше не позволило бы использовать библиотеки вроде LibreSSL и BearSSL, которые во всём остальном не хуже OpenSSL.
Разработчики и разработчицы клиентов и серверов, которые выбрали поддерживать TLS 1.2, должны в идеале позволять использовать только наборы шифров, обеспечивающие схожий с TLS 1.3 уровень безопасности. В частности, такое программное обеспечение должно: