よくある問題とバグの報告

Matt Gaunt

ウェブプッシュで問題が発生した場合、問題のデバッグやヘルプの検索が難しいことがあります。このドキュメントでは、一般的な問題の概要と、Chrome または Firefox でバグが見つかった場合の対処方法について説明します。

プッシュのデバッグに入る前に、Service Worker 自体のデバッグ、ファイルの更新、登録の失敗、または一般的な異常な動作に関する問題が発生することがあります。サービス ワーカーの開発を初めて行う場合は、サービス ワーカーのデバッグに関する優れたドキュメントをぜひご覧ください。

ウェブプッシュの開発とテストでは、2 つの異なる段階を確認する必要があります。それぞれに、独自の一般的な問題があります。

• メッセージの送信: メッセージが正常に送信されることを確認します。201 HTTP コードが返されます。まだログインしていない場合:
  • 承認エラーを確認する: 承認エラー メッセージが表示された場合は、承認に関する問題のセクションをご覧ください。
  • その他の API エラー: 201 以外のステータス コード レスポンスを受け取った場合は、HTTP ステータス コードのセクションで問題の原因に関するガイダンスをご覧ください。
• メッセージの受信: メッセージを正常に送信できたが、ブラウザでメッセージが受信されない場合:
  • 暗号化の問題を確認する: ペイロードの暗号化に関する問題のセクションをご覧ください。
  • 接続の問題を確認する: Chrome で問題が発生している場合は、接続に問題がある可能性があります。詳細については、接続の問題のセクションをご覧ください。

プッシュ メッセージを送受信できず、このドキュメントの関連セクションが問題のデバッグに役立たない場合は、プッシュ メカニズム自体にバグが見つかった可能性があります。この場合は、バグレポートの作成セクションを参照して、バグの修正プロセスを迅速化するために必要なすべての情報を含む適切なバグレポートを提出してください。

始める前に 1 つお伝えしておきたいのは、Firefox と Mozilla AutoPush サービスのエラー メッセージは非常に優れているということです。問題が解決しない場合は、Firefox でテストして、より有用なエラー メッセージが表示されるかどうかを確認してください。

承認に関する事象

認可の問題は、デベロッパーがウェブプッシュを使い始めるときに直面する最も一般的な問題の一つです。これは通常、サイトのアプリケーション サーバーキー（VAPID キー） の構成に問題がある場合に発生します。

Firefox と Chrome の両方でプッシュをサポートする最も簡単な方法は、subscribe() 呼び出しで applicationServerKey を指定することです。デメリットは、フロントエンドとサーバーの鍵に不一致があると、認可エラーが発生することです。

Chrome と FCM

FCM をプッシュ サービスとして使用する Chrome の場合、アプリケーション サーバーキーに関連するさまざまなエラーに対して、FCM から UnauthorizedRegistration レスポンスが返されます。

次のいずれかの状況で UnauthorizedRegistration エラーが発生します。

• FCM へのリクエストで Authorization ヘッダーを定義できなかった場合。
• ユーザーの登録に使用されたアプリケーション キーが、Authorization ヘッダーの署名に使用されたキーと一致しません。
• JWT の有効期限が無効です。つまり、有効期限が 24 時間を超えているか、JWT の有効期限が切れています。
• JWT の形式が正しくないか、無効な値が含まれています。

完全なエラー レスポンスは次のようになります。

<html>
  <head>
    <title>UnauthorizedRegistration</title>
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <h1>UnauthorizedRegistration</h1>

    <h2>Error 400</h2>
  </body>
</html>

Chrome でこのエラー メッセージが表示された場合は、Firefox でテストして、問題に関する詳細情報が得られるかどうかを確認してください。

Firefox と Mozilla AutoPush

Firefox と Mozilla AutoPush には、Authorization の問題に関するわかりやすいエラー メッセージが用意されています。

Authorization ヘッダーがプッシュ リクエストに含まれていない場合も、Mozilla AutoPush から Unauthorized エラー レスポンスが返されます。

{
  "errno": 109,
  "message": "Request did not validate missing authorization header",
  "code": 401,
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "error": "Unauthorized"
}

JWT の有効期限が切れている場合も、Unauthorized エラーが発生し、トークンの有効期限が切れていることを説明するメッセージが表示されます。

{
  "code": 401,
  "errno": 109,
  "error": "Unauthorized",
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "message": "Request did not validate Invalid bearer token: Auth expired"
}

ユーザーが登録されたときと Authorization ヘッダーが署名されたときでアプリケーション サーバーキーが異なる場合、Not Found エラーが返されます。

{
  "errno": 102,
  "message": "Request did not validate invalid token",
  "code": 404,
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "error": "Not Found"
}

最後に、JWT に無効な値がある場合（たとえば、「alg」の値が予期しない値の場合）、Mozilla AutoPush から次のエラーが返されます。

{
  "code": 401,
  "errno": 109,
  "error": "Unauthorized",
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "message": "Request did not validate Invalid Authorization Header"
}

HTTP ステータス コード

プッシュ サービスから 201 以外のレスポンス コードが返される原因となる問題はさまざまです。以下に、HTTP ステータス コードと、ウェブプッシュに関連する意味を示します。

ステータス コード	説明
429	リクエスト数が多すぎます。アプリケーション サーバーがプッシュ サービスのレート制限に達しました。サービスからのレスポンスには、別のリクエストを送信できるようになるまでの時間を示す「Retry-After」ヘッダーが含まれている必要があります。
400	無効なリクエストです。いずれかのヘッダーが無効であるか、形式が正しくありません。
404	見つかりませんでした。この場合は、バックエンドから PushSubscription を削除し、ユーザーが再度登録する機会を待つ必要があります。
410	Gone. 定期購入は無効になっているため、バックエンドから削除する必要があります。これは、`PushSubscription` で `unsubscribe()` を呼び出すことで再現できます。
413	ペイロード サイズが大きすぎます。プッシュ サービスがサポートする必要があるペイロードの最小サイズは 4,096 バイト（4 KB）です。これより大きいと、このエラーが発生する可能性があります。

HTTP ステータス コードがこのリストにない場合や、エラー メッセージが役に立たない場合は、ウェブプッシュ プロトコルの仕様を確認して、ステータス コードが使用されるシナリオとともにステータス コードが参照されているかどうかを確認します。

ペイロードの暗号化に関する問題

プッシュ メッセージを正常にトリガーできる（つまり、ウェブプッシュ サービスにメッセージを送信して 201 レスポンス コードを受信する）にもかかわらず、サービス ワーカーでプッシュ イベントがトリガーされない場合は、通常、ブラウザが受信したメッセージを復号できなかったことを示しています。

この場合、Firefox の DevTools コンソールに次のようなエラー メッセージが表示されます。

Chrome でこの問題が発生しているかどうかを確認するには、次の操作を行います。

1. about://gcm-internals にアクセスし、[Start Recording] ボタンをクリックします。

1. push メッセージをトリガーし、[Message Decryption Failure Log] を確認します。

ペイロードの復号に問題がある場合は、上記のようなエラーが表示されます。（[詳細] 列の AES-GCM decryption failed メッセージに注目してください）。

暗号化の問題をデバッグするのに役立つツールがいくつかあります。

• Peter Beverloo 氏による Push Encryption Verifier ツール。
• ウェブプッシュ: Mozilla によるデータ暗号化テストページ

接続の問題

サービス ワーカーでプッシュ イベントを受信しておらず、復号エラーも表示されない場合は、ブラウザがプッシュ サービスに接続できていない可能性があります。

Chrome では、about://gcm-internals の [Receive Message Log]（原文ママ）を調べることで、ブラウザがメッセージを受信しているかどうかを確認できます。

メッセージがすぐに届かない場合は、ブラウザの接続ステータスが CONNECTED であることを確認してください。

「CONNECTED」でない場合は、現在のプロファイルを削除して新しいプロファイルを作成する必要があります。それでも問題が解決しない場合は、以下に示すようにバグレポートを提出してください。

バグレポートの作成

上記の方法で問題が解決せず、問題の原因がわからない場合は、問題が発生しているブラウザに対して問題を報告してください。

Chrome の場合は、https://bugs.chromium.org/p/chromium/issues/list で問題を報告します。 Firefox の場合は、https://bugzilla.mozilla.org/ で問題を報告します。

適切なバグレポートを提供するには、次の詳細情報を提供する必要があります。

• テストに使用したブラウザ（Chrome バージョン 50、Chrome バージョン 51、Firefox バージョン 50、Firefox バージョン 51 など）。
• 問題を示す PushSubscription の例。
• リクエストの例（ヘッダーを含む、プッシュ サービスへのネットワーク リクエストの内容など）を含めます。
• ネットワーク リクエストからのレスポンスの例も記載してください。

再現可能な例（ソースコードまたはホストされているウェブサイト）を提供していただければ、問題の診断と解決を迅速に行うことができます。

次のステップ

• ウェブプッシュ通知の概要
• プッシュの仕組み
• ユーザーの登録
• 権限の UX
• ウェブプッシュ ライブラリを使用したメッセージの送信
• ウェブプッシュ プロトコル
• push イベントの処理
• 通知の表示
• 通知の動作
• 一般的な通知パターン
• プッシュ通知に関するよくある質問
• よくある問題とバグの報告

Codelab

• プッシュ通知クライアントを構築する
• プッシュ通知サーバーを構築する