HTML 5を修正する必要性について

現在の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を作成できる人はいますか？