💾 Archived View for geminiprotocol.net › docs › ja › best-practices.gmi captured on 2024-08-31 at 12:04:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
本文書では、様々な慣例や忠言が記されており、Geminiプロトコルを実装したり使ったりする人を対象にしています。内容はプロトコルの仕様で必須とされていないものの、一般にはそうすると良いとされることです。Geminiソフトウェアを書いたり、Geminiサイトを構築したりするときは、一般的にはこちらの忠告に従うべきです。ただし、そうしない理由があるのであればその限りではありません。
Geminiサーバーからクライアントに、提供するファイルのMIME種別を伝える必要があります。サーバーにとってファイルのMIME種別を判別する一番便利な方法は、ファイル名の拡張子によるものです。こうした対応付けはほぼ充分に標準化されています（そしてunixシステムには、完全な一覧として/etc/mime.typesがあることがしばしばです）。しかし残っている問題というのは、Geminiで定義されているtext/gemini種別で提供されるファイルをどう認識すべきかということです。
現在、Geminiサーバーではこの目的で.gmiや.geminiを拡張子として使っているようです。また、新しいサーバーでは、新しいものを加えたり混ぜたりするのではなく、これらの選択肢のいずれかないし両方に対応することが強く勧められます。
ウェブサーバーの慣例に従うと、ファイルシステムのディレクトリに対応付けられたパスに対する要求を受け取ったとき、かつそのディレクトリにindex.gmiやindex.geminiのファイルが存在するとき、そのパスに対してこのファイルが提供されます。
Geminiサーバーからは、提供するファイルの大きさについてクライアントに伝えません。このことで、サーバーの処理の失敗により接続が不完全に閉じられたことを検出するのが難しくなることがあります。この危険性はファイルの大きさに伴って増加します。
Geminiでは大きなファイルの圧縮への対応はありませんし、ファイルの破損を検出できるようにするチェックサムにも対応していません。こうした危険性もまた、ファイルの大きさに伴って増加します。
こうした理由があって、Geminiでは「とても大きな」ファイルの転送にはあまり適していません。厳密に何が「とても大きな」ものに数えられるのかは、使われるインターネット接続の速度と信頼性と、利用者の忍耐の度合いによります。大雑把には、100MiBより大きいファイルは別の方法で提供するのが最善と考えてよいでしょう。
もちろん、GeminiではURLスキームのある任意のプロトコルで他のオンライン内容へのリンクに対応しています。そのためHTTPS、BitTorrent、IPFSや他の食指の動くもので提供される大きなファイルへ、Gemini文書からリンクすることはできます。
Geminiでは、text/* MIME種別の「charset」引数で任意のテキストエンコーディングに対応しています。これにより、不明瞭な地域的なエンコーディングの仕組みで「旧式の」テキスト内容を提供できます。
ただ、新しい内容については、UTF-8だけを使ってください。お願いします。どうかお願いします。Geminiの仕様では、クライアントはUTF-8のテキストを扱えることを必須としています。他のエンコーディングの対応についてはクライアントに一任しており、保証はされていません。UTF-8で内容を提供することは利用可能性を最大化することであり、UTF-8のみに対応する単純なクライアントにとっての利便性を最大化することでもあるのです。
リダイレクトはGeminiに当初より含まれていました。サイトの再構築ができるようにしたり、サーバー間でサイトを移転したりするとき、既存のリンクを壊さずに済ませるためです。大きな、内部で接続された文書の空間にこのような機能がなければ、必然的に「脆い」ものになってしまいます。
しかし、リダイレクトは、一般的には、不愉快なものです。プロトコルの等価性を低め、辿るべきリンクの選択をするよう知らされるので使いづらくなり、人々のオンラインでの活動の情報を第三者に漏らしかねないからです。Geminiでのリダイレクトは（クッキーやリファラーヘッダーなどがないため）HTTPよりは悪くありませんが、控えめに言って邪悪であることには変わりありません。
そういうわけで、軽率にリダイレクトを使うのは控えてください！URL短縮器のようなものはほとんど利点のないものです。一般に、リンク切れを避けること以外では、リダイレクトの仕様については熟慮してください。
クライアントでは利用者にプロンプトを出してリダイレクトを辿るか決めてもらったり、自動的にリダイレクトを辿れるようにしたりしています。自動的にリダイレクトを辿るクライアントを書いているのであれば、以下の問題点に留意すべきです。
構成が誤っていたり、悪意のあるGeminiサーバーでは望ましくないリダイレクトが提供されることがあります。無考えにリンクを辿るクライアントでは、リダイレクトの無限ループに囚われたり、とても長いリダイレクトの連鎖を経なければならないことがありえます。クライアントを頑健にするには、こうした状況を検出したり、そうした状況に応じて動作したりするだけの機能が必要です。一番単純な実装としては、N回以上連続するリダイレクトを辿ることを拒否することです。Nは5より大きくしないことをお勧めします。これはHTTPの元来の勧告に従ったものです（RFC-2068を参照）。
プロトコル間リダイレクト（要はGeminiからGopherのような何か別のものへリダイレクトすること）はGeminiの枠内でできますが、全面的にお勧めしません。しかし、構成が誤っていたり悪意があったりするサーバーでは、常にこうしたリダイレクトができるようになっているでしょう。そのため、クライアントをしっかり書く際は、そうしたリダイレクトを検出してそれに応じて応答する用意をすべきです。
一般に自動でリダイレクトを辿るクライアントでも、HTTPやGopherといったTLSで守られていないプロトコルへのリダイレクトで提供されたときは、そしてクライアントでこれらのプロトコルへの対応が実装されているときは、利用者に警告して明示的に確認することを強くお勧めします。これにより、意図しない平文での転送が避けられます。
TLS 1.2はGeminiでは不承不承に許されています。一方でTLS 1.3は劇的に単純で、多くの安全でない暗号解読の基本要素が除かれています。TLS 1.2が許されているのは、現時点でOpenSSLのみがTLS 1.3に充分に対応していると思われるからであって、TLS 1.3以降を要求するとLibreSSLやBearSSLといったライブラリの使用が推奨されなくなるでしょう。TLS 1.3への対応を除けば、OpenSSLよりこれらのライブラリが遥かに推奨されます。
クライアントとサーバーの作成者で、TLS 1.2に対応することを選択される方は、TLS 1.3と同等の安全性を提供する暗号スートのみを使えるようにするのが理想です。特に、そのようにするソフトウェアは以下とすべきです。