Problèmes courants et signalement de bugs

Matt Gaunt

Lorsque vous rencontrez un problème avec le push Web, il peut être difficile de le déboguer ou de trouver de l'aide. Ce document décrit certains des problèmes courants et ce que vous devez faire si vous avez détecté un bug dans Chrome ou Firefox.

Avant de nous pencher sur le débogage du mode push, vous rencontrez peut-être des problèmes avec les service workers eux-mêmes, la mise à jour du fichier, l'échec de l'enregistrement ou un comportement tout simplement inhabituel. Il existe un document très intéressant sur le débogage des service workers. Nous vous recommandons vivement de le consulter si vous débutez dans le développement de service workers.

Lors du développement et du test de la fonctionnalité Web push, vous devez suivre deux étapes distinctes, chacune présentant son propre ensemble de problèmes / problèmes courants:

  • Envoyer un message : assurez-vous que l'envoi des messages est réussi. Vous devriez recevoir un code HTTP 201. Si vous n'êtes pas :
    • Rechercher les erreurs d'autorisation:si vous recevez un message d'erreur d'autorisation, consultez la section Problèmes d'autorisation.
    • Autres erreurs de l'API : si vous recevez une réponse avec un code d'état autre que 201, consultez la section sur les codes d'état HTTP pour connaître l'origine du problème.
  • Réception d'un message: si vous parvenez à envoyer un message, mais qu'il n'est pas reçu dans le navigateur :

Si vous ne parvenez pas à envoyer ni à recevoir de message push, et que les sections pertinentes de ce document ne vous aident pas à résoudre le problème, vous avez peut-être détecté un bug dans le mécanisme push lui-même. Dans ce cas, consultez la section Signaler un bug pour envoyer un bon rapport de bug avec toutes les informations nécessaires pour accélérer le processus de correction.

Avant de commencer, je tiens à préciser que Firefox et le service Mozilla AutoPush affichent d'excellents messages d'erreur. Si vous ne savez pas quel est le problème, testez dans Firefox pour voir si un message d'erreur plus utile s'affiche.

Problèmes d'autorisation

Les problèmes d'autorisation sont l'un des problèmes les plus courants rencontrés par les développeurs lorsqu'ils commencent à utiliser le push Web. Il s'agit généralement d'un problème de configuration des clés de serveur d'application (également appelées clés VAPID) d'un site.

Le moyen le plus simple d'accepter le push dans Firefox et Chrome consiste à fournir un applicationServerKey dans l'appel subscribe(). L'inconvénient est que toute divergence entre les clés de votre interface utilisateur et celles du serveur entraînera une erreur d'autorisation.

Sur Chrome et FCM

Pour Chrome, qui utilise FCM comme service de transfert, vous recevrez une réponse UnauthorizedRegistration de FCM pour un certain nombre d'erreurs différentes, toutes impliquant les clés du serveur d'application.

Vous recevrez une erreur UnauthorizedRegistration dans l'une des situations suivantes :

  • Si vous ne définissez pas d'en-tête Authorization dans la requête envoyée à FCM.
  • La clé d'application utilisée pour abonner l'utilisateur ne correspond pas à celle utilisée pour signer l'en-tête d'autorisation.
  • L'expiration n'est pas valide dans votre jeton JWT, c'est-à-dire que l'expiration dépasse 24 heures ou que le jeton JWT a expiré.
  • Le jeton JWT est mal formé ou comporte des valeurs non valides.

La réponse d'erreur complète se présente comme suit :

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

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

Si vous recevez ce message d'erreur dans Chrome, essayez d'effectuer un test dans Firefox pour voir si cela peut vous fournir plus d'informations sur le problème.

Firefox et Mozilla AutoPush

Firefox et Mozilla AutoPush fournissent un ensemble de messages d'erreur conviviaux pour les problèmes Authorization.

Si l'en-tête Authorization n'est pas inclus dans votre requête push, vous recevrez également une réponse d'erreur Unauthorized de Mozilla AutoPush.

{
  "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"
}

Si l'expiration de votre jeton JWT a expiré, vous recevrez également une erreur Unauthorized avec un message expliquant que le jeton a expiré.

{
  "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"
}

Si les clés du serveur d'application sont différentes entre le moment où l'utilisateur a été abonné et celui où l'en-tête d'autorisation a été signé, une erreur Not Found est renvoyée :

{
  "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"
}

Enfin, si vous avez une valeur non valide dans votre JWT (par exemple, si la valeur "alg" est une valeur inattendue), vous recevrez l'erreur suivante de 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"
}

Codes d'état HTTP

Plusieurs problèmes peuvent entraîner l'envoi d'un code de réponse autre que 201 d'un service push. Vous trouverez ci-dessous la liste des codes d'état HTTP et leur signification par rapport aux notifications Web Push.

Code d'état Description
429 Trop de requêtes. Votre serveur d'application a atteint une limite de débit avec un service de transfert. La réponse du service doit inclure un en-tête "Retry-After" pour indiquer le délai avant qu'une autre requête puisse être envoyée.
400 Demande incorrecte. L'un de vos en-têtes n'est pas valide ou n'est pas correctement formaté.
404 Introuvable. Dans ce cas, vous devez supprimer le PushSubscription de votre backend et attendre une opportunité de réabonner l'utilisateur.
410 disparu. L'abonnement n'est plus valide et doit être supprimé de votre backend. Pour reproduire ce problème, appelez "unsubscribe()" sur un "PushSubscription".
413 Charge utile trop grande. La charge utile minimale qu'un service de distribution doit prendre en charge est de 4 096 octets (ou 4 ko). Une valeur plus élevée peut entraîner cette erreur.

Si le code d'état HTTP ne figure pas dans cette liste et que le message d'erreur n'est pas utile, consultez la spécification du protocole Web Push pour voir si le code d'état est référencé, ainsi qu'un scénario dans lequel il peut être utilisé.

Problème de chiffrement de la charge utile

Si vous parvenez à déclencher un message push (c'est-à-dire, en envoyant un message à un service Web push et en recevant un code de réponse 201), mais que l'événement push ne se déclenche jamais dans votre service worker, cela signifie normalement que le navigateur n'a pas réussi à déchiffrer le message reçu.

Dans ce cas, un message d'erreur doit s'afficher dans la console DevTools de Firefox :

Outils de développement Firefox avec message de déchiffrement.

Pour vérifier si le problème est bien lié à la taille du fichier dans Chrome, procédez comme suit :

  1. Accédez à about://gcm-internals, puis cliquez sur le bouton "Start Recording" (Démarrer l'enregistrement).

Enregistrement des éléments internes de GCM Chrome.

  1. Déclenchez un message push, puis consultez le journal des échecs de déchiffrement des messages.

Journal de déchiffrement des données internes GCM.

En cas de problème de déchiffrement de la charge utile, une erreur semblable à celle affichée ci-dessus s'affiche. (Notez le message AES-GCM decryption failed dans la colonne "Détails".)

Voici quelques outils qui peuvent vous aider à déboguer le chiffrement si c'est votre problème :

Problème de connexion

Si vous ne recevez pas d'événement de transfert dans votre service worker et que vous ne voyez aucune erreur de déchiffrement, il est possible que le navigateur ne parvienne pas à se connecter à un service de transfert.

Dans Chrome, vous pouvez vérifier si le navigateur reçoit des messages en examinant le "Journal de réception des messages" (sic) dans about://gcm-internals.

Les composants internes de GCM reçoivent le journal des messages.

Si le message n'arrive pas dans les temps, vérifiez que l'état de la connexion de votre navigateur est CONNECTED :

État de la connexion des composants internes de GCM.

Si l'état n'est pas "CONNECTÉ", vous devrez peut-être supprimer votre profil actuel et en créer un autre. Si le problème persiste, veuillez envoyer un rapport de bug comme suggéré ci-dessous.

Signaler des bugs

Si aucune des solutions ci-dessus ne résout votre problème et qu'aucun signe ne permet de déterminer la cause du problème, veuillez signaler le problème au navigateur avec lequel vous rencontrez le problème :

Pour Chrome, signalez le problème sur la page suivante : https://bugs.chromium.org/p/chromium/issues/list. Pour Firefox, signalez le problème sur la page suivante : https://bugzilla.mozilla.org/.

Pour que votre rapport de bug soit efficace, vous devez fournir les informations suivantes :

  • Navigateurs que vous avez testés (par exemple, Chrome 50, Chrome 51, Firefox 50, Firefox 51)
  • Exemple de PushSubscription illustrant le problème.
  • Incluez tous les exemples de requêtes (c'est-à-dire le contenu des requêtes réseau adressées à un service push, y compris les en-têtes).
  • Incluez également tous les exemples de réponses des requêtes réseau.

Si vous pouvez fournir un exemple reproductible, que ce soit du code source ou un site Web hébergé, cela accélère souvent le diagnostic et la résolution du problème.

Étapes suivantes

Ateliers de programmation