a 要素、area 要素 ping 属性 (HTML)

[67] ping 属性は、リンクをたどる際に同時にアクセスするべき URL を指定するものです。

仕様書

文脈

[74] 著者は JavaScript その他の方法で ping 属性を使わずとも同じことが実現できるわけですが、 ping 属性を使えば何を行うか (どこがリンク先で、どこに ping を行うか) 利用者・利用者エージェントに対して明確にでき、利用者エージェントが処理タイミングを調整するなどして利用者の体験を向上させることが期待できます。従って、著者は他の方法ではなく ping を使うべき (encourage) です >>50。

[75] 例えば検索エンジンは、直接リンク先サイトにリンクせず、一旦自社サイトにリンクして、そこからリダイレクトすることで、どのサイトが選択されたかを集計することができます。

[76] これを ping による集計に切り替えることで、 ping へのアクセスは Webブラウザーが裏で行うこととなるので、利用者はリダイレクト分の余計な時間をかけずに目的サイトに移動できます。 (利用者の体験が向上するのは、検索エンジンにとっても好ましいことです。)

[77] また、利用者は正しいリンク先の URL をステータスバーで確認できます。

[78] 加えて、利用者が潔癖なら Webブラウザーの設定を変更して ping 属性を無効化することで、集計を拒否できます。 (検索エンジンにとっては改善のためのデータを収集する機会が失われるので嬉しくはありませんが、それを快く思わない人から無理に収集するのもまた意に反するでしょう。リダイレクトその他独自の方法では、利用者にその選択肢を与えることも困難です。)

利用者の設定

[63] 利用者エージェントは、利用者が ping 属性の挙動を調節できるようにするべきです >>50。

[65] 例えば、 Referer: ヘッダーの送信有無と同時に設定可能とすることができます >>50。

[66] ping 属性をすべて無視しても構いませんし、第三者 URL を無視するなどの判断を挟んでも構いません。 >>50

処理

[51] ping 属性の処理は、要素要素とリンク先の対象URLについて、次のようにしなければなりません >>50。

[52] 値を、要素の ping 属性値に設定します。
[53] 値が null なら、ここで停止します。
[54] リストを、値に文字列を間隔で分割を適用した結果に設定します。
[55] リストの各要素字句について、
1. [56] URL を、要素の節点文書に相対に字句を構文解析した結果に設定します。
2. [57]
  - [58] URL が失敗でない
  - [59] URL の scheme が HTTP(S) scheme である
  - [60] 利用者エージェント依存の条件を満たす (>>63)
  ... のすべてを満たす場合、
  1. [61] 要求を fetch します。
    要求
    URL
    URL
    メソッド
    POST
    ヘッダーリスト
    Ping-From
    要素の節点文書の起源と URL の起源が同じ起源か、 要素の節点文書のHTTPS状態が none なら、 要素の節点文書のURL。それ以外なら、 null。
    Ping-To
    対象URL
    本体
    PING
    クライアント
    要素の節点文書の関連する設定群オブジェクト
    終点
    空文字列
    credentialsモード
    include
    参照元
    no-referrer
    URL credentials利用
    真
    process response
    [64] 本 fetch を abort して構いません。

[62] fetch の結果は使われません。 fetch は並列に行うことができます >>50。結果が使われない以上、どう実装されているか著者が直接感知することはできません。

[42] ping 属性の処理は、ハイパーリンクをたどる処理から呼び出されます。

[43] 趣旨からするとダウンロード時にも ping が送信されるべきと思われますが、なぜかそうなっていません。 (ハイパーリンクをたどることにより navigate が発生し、それがダウンロードに至った場合には、最初のたどった時点で ping が送信されます。)

実装がどうしているのかは不明。

[69] Ping-From: ヘッダーは、 https: のページの場合、同一起源でなければ送信されません。つまり同一起源ポリシーが適用されます。 http: の場合は、異なる起源であっても送信されます。 Referer: ヘッダーの動作 (参照元ポリシー no-referrer-when-downgrade) に倣ったものと思われますが、同一起源でなければならない分、少し厳しくなっています。

[70] そもそも ping の URL は著者が指定するもので、著者は任意の URL を指定でき、 URL に自ページの URL を含めることもできるわけですから、この制約は情報の漏洩を防ぐものではありません。 XHR や Fetch を使って Ping-From: の指定された要求を送信することはできますから、第三者の不正なスクリプトからの送信を防げるものでもありません。この制約が何のためのものなのかは不明です。

[71] >>70 CORS preflight でOKが出ないと POST + Ping-From: は送れないのか。それなら、 HTTPS を使っていれば、不正な要求と区別できる。

[72] >>14 で削除された仕様書のコメントによると元々 Referer: を含めないことにしていたのは他の POST と区別できるようにするためらしい。既存のサーバーの CSRF などの検査を壊さないように Referer: とは別にほぼ同じ意味の Ping-From: を設定することにしたようである。更に付け加えると、 ping は CORS より古いので、 Ping-From: が他の方法で指定されて異なる起源に送信される、ということは想定されていない模様。

[73] >>20 あたりも参照。

実装

[80] Chrome、Opera、Safari が実装しています。

[81] Firefox にも実装は一応されていますが、標準設定では無効になっています。

[82] IE・Edge は未実装です。

[83] Firefox と Edge は Beacon には対応しています。

歴史

誕生

[15] 2005年10月に Web Applications 1.0 に追加されました。

[1] Mozilla Links 日本語版: Firefox のプライバシー問題 http://mozlinks-jp.blogspot.com/2006/01/firefox_21.html

あれだ、やっぱりpingもタグなのかよw (名無しさん 2006-01-22 01:27:04 +00:00)

[2] Bug 319368 - Implement <a ping> https://bugzilla.mozilla.org/show_bug.cgi?id=319368 (名無しさん 2006-01-27 01:03:54 +00:00)

[3] 本当の問題は安全性よりも (賛成派の主張の通り、少なくても今より危険になるわけではない)、POSTされることではないか。もちろんHTTPやREST的にはPOSTの方が適当なのだが、 tag soup application開発者はしばしば (formではなく) aでPOSTすることを望んでいる (あちこちの掲示板で頻出の質問)。 pingがそれに濫用される可能性がないだろうか。

ただしpingに対する応答はレンダリングされないので、彼らの需要を満たせるのかどうかには疑問もあるが。

pingを使ってPOSTして、鯖側でセッション管理 (もちろんREST制約違反)、hrefとセッション情報 (Cookie) でGETして結果を得る、ただしpingとhrefのどちらが先に処理されるかはわからないのでRefreshでもして待つ、などという裏技が紹介される日が来る・・・かもしれない。もはや何をしたかったのかよくわからないがw

(名無しさん 2006-01-27 08:07:12 +00:00)