1. はじめに
[はじめにがここに入ります]
1.1. 例
Reporting-Endpoints: default="https://example.com/reports"
2. 概念
2.1. クラッシュ
2.2. メモリ不足
2.3. 応答なし
3. クラッシュレポート
クラッシュレポートは、 ブラウザー(またはページに必要なそのプロセスのいずれか)が クラッシュしたため、ユーザーがそのページを使い続けられなかったことを示す。 セキュリティ上の理由により、クラッシュについては一意の識別子 (ブラウザーベンダーが解釈できるもの)と、任意でクラッシュの理由 ("oom" など)を除き、詳細は伝達されない。
クラッシュレポートは、report type "crash" を持つ。
dictionary :CrashReportBody ReportBody {DOMString ;reason DOMString ;stack boolean ;is_top_level DocumentVisibilityState ;visibility_state object ; };crash_report_api
クラッシュレポートの body は、JavaScript では
CrashReportBody
によって表され、次のフィールドを含む:
-
reason: 既知であれば発生したクラッシュの種類の より具体的な分類であり、そうでなければ省略される。有効な reason 文字列を以下に示す。
| 理由 | 説明 |
|---|---|
| oom | ページがメモリ不足になった。 |
| unresponsive | ページが応答しないため強制終了された。 |
-
stack: 次のすべてが真である場合における、 クラッシュ時点の JavaScript コールスタックの文字列表現であり、 そうでなければ省略される:
-
クラッシュの reason が "unresponsive" である。
-
クラッシュした Document における
include-js-call-stacks-in-crash-reportsのポリシー値がtrueである。 -
クラッシュした文書からコールスタックを復元できる。
stack に使用される文字列表現は、 Error.prototype.stack プロパティで使用されるものと同じである。
-
-
is_top_level: クラッシュした
Documentが top-level traversable に属していたかどうかを表す boolean。 -
visibility_state: 文字列値 "
visible" または "hidden" であり、ウェブプラットフォームにDocument.visibilityStateを通じて公開されるDocumentVisibilityStateenum と一致する。 これは、クラッシュしたDocumentがホストされていた視覚ビューポートが少しでも可視であったか、 完全に覆い隠されていたかを表す。 -
crash_report_api: クラッシュした
DocumentのCrashReportContextの backing buffer ID メンバーによって識別される、 user agent の crash report buffers マップ内のメモリバッファを デシリアライズして得られる、任意のキー/値データの JSON 辞書。 このバッファは JSON 形式の文字列としてデシリアライズされ、そのキーと値はこのCrashReportBodyのanyオブジェクトメンバーに追加される。
注: クラッシュレポートは JavaScript から観測できない。 定義上、それらを受け取るはずのページが受け取ることができないためである。 CrashReportBody の IDL 記述は、帯域外レポートに埋め込むことができる JSON シリアライズ可能なインターフェイスを提供するために、この仕様内に存在する。
3.1. クラッシュ レポートの配信優先度
crash-reporting endpoint が指定されている場合、クラッシュレポートはそこへ配信される。
そうでなく、default endpoint が指定されている場合、クラッシュレポートはそこへ配信される。
どちらの endpoint も指定されていない場合、クラッシュレポートは配信されない。
4. CrashReportContext
インターフェイス
partial interface Window {readonly attribute CrashReportContext crashReport ; };
各 Window
オブジェクトは、関連付けられた crashReport を持つ。これは
CrashReportContext
インスタンスであり、Window
と同時に作成される。
crashReport getter の手順は次のとおりである:
-
this の relevant global object の associated Document が fully active でない場合、null を返す。
-
this の relevant global object の crashReport オブジェクトを返す。
[Exposed =Window ]interface {CrashReportContext Promise <undefined >initialize (unsigned long long );length undefined set (DOMString ,key DOMString );value undefined delete (DOMString ); };key
各 CrashReportContext
オブジェクトは、関連付けられた internal map を持つ。
これは map であり、その keys
と values はどちらも DOMString
である。
user agent は、関連付けられた crash report buffers を持つ。これは map であり、その keys は unique internal values、その values は implementation-defined 値である。
注: internal map は、 最終的にクラッシュレポートに現れるデータのマップ表現であり、このデータを map セマンティクスを介して扱いやすくするために存在する。ただし、この仕様の実装、 とくにサイト分離をサポートする実装は、最終的にはその内容全体を、 user agent の crash report buffers マップによって追跡される、裏側の共有メモリバッファへシリアライズする可能性が高い。 その マップの values は、ウェブプロセスと、 ウェブプロセスがクラッシュしたときにクラッシュレポートの送信を担当する OS プロセスとにまたがる メモリバッファになることが期待され、その時点では internal map はもはや読み取れない。
各 CrashReportContext
オブジェクトは、関連付けられた backing buffer
ID を持つ。これは null または unique
internal value であり、初期値は null である。
各 CrashReportContext
オブジェクトは、関連付けられた is buffer
initialized boolean を持ち、初期値は false である。
注: このメンバーは、 this の backing buffer ID に関連付けられた 裏側のメモリバッファが初期化されると、非同期的に true に設定される。
各 CrashReportContext
オブジェクトは、関連付けられた unsigned long long
buffer length を持ち、初期値は 0 である。
注: これは initialize()
で一度だけ代入され、set()
のどの呼び出しでも
internal map を裏付けるメモリへ書き込める
最大バイト数を追跡する。
internal map は、
開発者へ CrashReportBody
として提供されるすべてのキー/値を保持するために使用される。
サイト分離を備えたブラウザーでは、このデータへ書き込む物理プロセスは、
そこから読み取り クラッシュレポートを送信するプロセスとは異なる。
したがって、実装はこのマップを 2 つのプロセスにまたがる共有メモリ
バッファとして維持することが期待される。これは、この API の Chromium 実装が行っていることである。
initialize(length) メソッドの手順は
次のとおりである:
-
this の relevant global object の associated Document が fully active でない場合、throw a new "
InvalidStateError"DOMExceptionする。注: これは拒否された
Promiseを通じてユーザーに表面化する。 -
this の backing buffer ID が非 null である場合、 throw a new "
InvalidStateError"DOMExceptionする。 -
length が 5 * 1024 * 1024 より大きい場合、throw a new "
NotAllowedError"DOMExceptionする。注: クラッシュレポート用メモリ バッファの上限は 5 メガバイトである。
-
this の buffer length を length に設定する。
-
this の backing buffer ID を、creating a new unique internal value の結果に設定する。
-
cachedThis を this とする。
-
promise を a new promise とする。
-
これらの手順を in parallel に実行する:
-
backing buffer ID を cachedThis の backing buffer ID とする。
-
length バイトの裏側のメモリストアを作成して初期化するため、 implementation-defined 手順を実行する。
-
そのようなバッファが作成された場合:
-
user agent の crash report buffers[backing buffer ID] をその buffer に設定する。
-
cachedThis の is buffer initialized を true に設定する。
-
-
cachedThis の relevant global object を指定して、 DOM manipulation task source 上の Queue a global task を行い、 promise を
undefinedで resolve する。
-
-
promise を返す。
set(key, value) メソッドの手順は
次のとおりである:
-
this の relevant global object の associated Document が fully active でない場合、throw a new "
InvalidStateError"DOMExceptionする。 -
this の is buffer initialized が false である場合、 throw a new "
InvalidStateError"DOMExceptionする。注: これは
initialize()が呼び出される前にも、 呼び出された 後 で返されたPromiseが解決される前にも false である。これは、set()が、backing buffer ID によって識別される 裏側のバッファが完全に初期化された場合にのみ機能することを保証する。 -
Set this の internal map[key] を value に設定する。
-
serialization を、 this の internal map を指定して、 serializing a JavaScript value to JSON bytes を行った結果とする。
-
serialization の size が this の buffer length より大きい場合:
-
Remove this の internal map[key]。
-
Throw a new "
NotAllowedError"DOMExceptionする。
-
-
backing buffer ID を this の backing buffer ID とする。
-
serialization を user agent の crash report buffers[backing buffer ID] に書き込む。
delete(key) メソッドの手順は次のとおりである:
-
this の relevant global object の associated Document が fully active でない場合、throw a new "
InvalidStateError"DOMExceptionする。 -
this の is buffer initialized が false である場合、 throw a new "
InvalidStateError"DOMExceptionする。 -
Remove this の internal map[key]。
-
serialization を、 this の internal map を指定して、 serializing a JavaScript value to JSON bytes を行った結果とする。
-
backing buffer ID を this の backing buffer ID とする。
-
serialization を user agent の crash report buffers[backing buffer ID] に書き込む。
5. Document Policy との統合
サイト作成者は、一部のレポートについて JavaScript コールスタックの記録を オプトインできる。
この仕様は、名前
include-js-call-stacks-in-crash-reports を持つ
configuration point を定義する。その型は boolean であり、デフォルト
値は false である。クラッシュ
報告が有効な Document で
true として構成されている場合、これによりクラッシュ時点の JavaScript
コールスタックの文字列表現がクラッシュレポートに含まれる。
6. 実装上の考慮事項
6.1. 配信
[REPORTING] は、 この仕様が依存するフレームワークを定義し、 高々ベストエフォートの配信機構を提供する。これはクラッシュの報告に関して とくに当てはまる。おそらく常に、単に報告できない特定の クラッシュ条件が存在する(たとえば、ユーザーエージェントのクラッシュ監視コード内で クラッシュが発生した場合や、ユーザーエージェントをホストしているコンピューターが突然 存在しなくなった場合など)。しかし、多くのクラッシュは 最新のブラウザーによって観測でき、その直接の原因を推測できる。
クラッシュレポートを実装するユーザーエージェントは、その文書を担当するプロセスが クラッシュしたり、オペレーティングシステムによって終了されたりした場合でも機能し続ける 方法で、文書のクラッシュを監視するよう試みるべきである。
このようなモニターを実装する方法は複数あり、特定のクラッシュ原因に対する 信頼性および堅牢性の水準はさまざまである。この仕様は、そのような特定の方法を 規定しようとはしない。
7. サンプルレポート
POST /reports HTTP/1.1
Host: example.com
...
Content-Type: application/reports+json
[{
"type": "crash",
"age": 42,
"url": "https://example.com/",
"user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0",
"body": {
"reason": "oom"
}
}]
8. セキュリティ上の考慮事項
一般的な帯域外報告に関するセキュリティ上の考慮事項についての議論は、 Reporting API § 8 Security Considerations を参照。
この節の残りの部分では、クラッシュ 報告に固有のセキュリティ上の考慮事項を議論する。
9. プライバシー上の考慮事項
一般的な帯域外報告に関するプライバシー上の考慮事項についての議論は、 Reporting API § 9 Privacy Considerations を参照。
この節の残りの部分では、クラッシュ 報告に固有のプライバシー上の考慮事項を議論する。