現在のHTML 5プロジェクトには、特に実用に適さない形式で
registerProtocolHandler（）関数が含まれています。 そして、私がこの結論に至った経緯について話すことは有益です。
ストーリーは広範になります。 自分に忍耐の余地を感じない人は、ハブラクラートの下に登らない方が良い。
2007年または2008年頃、サイト
http://fghi.pp.ru/がオープンしました。これは、Fidonetの電子メールシステムとFirefoxなどのブラウザの間のゲートのように機能します。 たとえば、誰かがFidonetに直接アクセスできないため、URLでFidonetメッセージを直接開くことができない場合
エリア：//Ru.Blog.Mithgol？msgid = 2：5063/88 + 49659a64
次に、URLを開いてWebゲートを使用できます
http://fghi.pp.ru/?area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64このゲートウェイは、FidonetハイパーリンクのいくつかのFGHI URLスキーム（
「area：// ...」 や「fecho：// ...」など）を処理します。
昨年、Firefox 3.0.xが登場しました。これは、registerProtocolHandler（）APIのWhatWG提案を実装したブラウザです。 Webサイトは、以前はブラウザーに知られていないURLスキームのハンドラーとして登録できるようになりました。 Fidonetブラウザー（HellEd
やNoSFeRaTUのGoldED +など）で徐々に具体化されていましたが、以前はインターネットブラウザーでは完全に不明であったFGHI Fidonet URLに類似したスキーム
。私はすぐにFidonetエコーメールを
FGHIゲートURLの作成者に伝え、彼にregisterProtocolHandler（）の利点を
説明しました。
area：//GanjaNet.Local/？msgid = 2：5063/88 + 48319a1f次に、FGHIゲートURLの作成者は、
「area：//」 および「fecho：//」ハイパーリンクのハンドラーとして誰でもゲートにアクセスして登録できる場所としてページ
http://fghi.pp.ru/handler.phpを作成し
ましたFirefox。ただし、この登録が完了した後でも、読者は
http://fghi.pp.ru/?area://FTSC_Public/ などのページに
アクセスし 、次のような
非表示形式で URLを確認します
。http://fghi.pp.ru/?area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781ゲートの作成者に、URLが次の
ような自然なFidonet形式で提供されない理由を尋ねました
。area：// FTSC_PUBLIC？msgid = 2：280/5555 + 48c0e781
その後、ゲート作成者は、WhatWG APIが不完全であり、registerProtocolHandler（）の呼び出しが成功したかどうか、URLスキームが実際に登録されたかどうか、次のページがサーバーによって提供されるまで登録されたままかどうかを判断する方法をサイトに提供しないことを説明しました。
このタスクを選択せずに実行できるように、HTML 5を拡張する必要があることは、私にとって非常に明白になりました。
おそらく現在のHTML 5標準のregisterProtocolHandler（）関数は、現在標準で記述されているため、
void （値を返さない）のままにするのに適しています。 ただし、WhatWGは、
protocolRegistered（ "area"）などの名前と、プロトコルが登録されているかどうかを確認する単一の引数
（プロトコルの名前）を持つ新しいブール（論理）関数を発明するのに適しています。
http://www.whatwg.org/specs/web-apps/current-work/#custom-handlersには、このようなプロトコル登録のセキュリティへの影響の可能性が記載されています。 個人的には、次の2つの考慮事項が思い浮かびます。
1）サイトがprotocolRegistered（）が真の値を返すまでregisterProtocolHandler（）関数を呼び出すことを意図している場合でも、ブラウザはjavascript登録要求によるユーザーの「混乱」、「スパム」を防止する必要があります。 ページ
http://fghi.pp.ru/handler.phpで 、Firefoxが通知を順番に表示し
ている
ことに既に気づきました （「fecho：//」「area：//」の 後に 、 登録「area：//」がユーザー
によって承認または拒否された）; この方法でおそらく十分です。
2）サイトは、プロトコルの登録について交渉することはできません。 たとえば、「ポルノアーカイブにログインして、
「mailto：」ハンドラをここに登録し、通信
相手のアドレスを収集して
スパムを 送信する」というシナリオは、
必ず防止する必要があります。 スキームを登録するときのブラウザーインターフェイスの単純なチェックマーク（「evil.example.org自体に表示される
mailtoリンクのみのハンドラーとしてevil.example.orgを登録します。」）サイトがprotocolRegistered（）trueを確認するには十分です。また、マウスでクリックしたときにハイパーリンク
「mailto：example@evil.example.org」がその
サイトのハンドラページ
につながったことを確認することもできましたが、他の害はありませんでした。
protocolRegistered（ "area"）関数が論理的な真実だけでなく、直接のハイパーリンク（上記の例では、
「http://fghi.pp.ru/?%s」）を返す可能性がある人もいるでしょう。
。 ただし、ハンドラページのイントラネットアドレスは、外部ネットワークに簡単に漏洩する可能性があります。 それに加えて（そして、これはおそらくもっと面白いでしょう）、
ハンドラーサイトは、ユーザーが好む（そして登録されたとして登録される）場合、非標準のアドレスを自然な形で送信する代わりに独自のプレフィックスを使用できます非標準URLの自然な外観のハンドラー）他のサイト、競合他社のサイト。 これは非常に明白なことなので、protocolRegistered（）バイナリ関数が最適な出力であると考えています。
registerProtocolHandler（）関数だけでは不十分な理由については、これがすべてです。
さて、Habrに質問をします。どうすれば潮流を変えることができますか？ Habréで、WhatWG
および（または） ブラウザ構築業界で、意思決定に影響を与え
、サイトビルダーにとってより完全で便利な方法
で URLスキームを登録するためのAPIを作成できる人はいますか？