Ta strona została przetłumaczona przez Cloud Translation API.

Typowe problemy i zgłaszanie błędów

Matt Gaunt

Gdy napotkasz problem z Web Push, może Ci być trudno go debugować lub znaleźć pomoc. Ten dokument zawiera opis częstych problemów i działań, które należy podjąć w przypadku znalezienia błędu w przeglądarce Chrome lub Firefox.

Zanim przejdziemy do debugowania push, być może występują problemy z samymi skryptami service worker, plik nie jest aktualizowany, nie udaje się zarejestrować lub zwykle działa to w nietypowy sposób. Dostępna jest świetna dokumentacja na temat debugowania mechanizmów Service Worker, którą zdecydowanie zachęcam do zapoznania się z informacjami dla osób, które dopiero zaczynają programować.

Podczas tworzenia i testowania web push należy wyróżnić 2 etapy, a każda z nich ma własny zestaw typowych problemów:

Wysyłanie wiadomości: sprawdź, czy wysyłanie wiadomości przebiega pomyślnie. Powinien wyświetlać się kod HTTP 201. Jeśli nie:
- Sprawdzanie błędów autoryzacji: jeśli zobaczysz komunikat o błędzie autoryzacji, zapoznaj się z sekcją Problemy z autoryzacją.
- Inne błędy interfejsu API: jeśli otrzymasz odpowiedź z kodem stanu inną niż 201, przeczytaj informacje o przyczynie problemu w sekcji Kody stanu HTTP.
Odbieranie wiadomości: jeśli możesz wysłać wiadomość, ale nie została ona odebrana w przeglądarce:
- Sprawdź problemy z szyfrowaniem: zapoznaj się z sekcją dotyczącą problemów z szyfrowaniem ładunku.
- Sprawdź, czy nie ma problemów z połączeniem: jeśli problem występuje w Chrome, może to być połączenie. Więcej informacji znajdziesz w sekcji Problemy z połączeniem.

Jeśli nie możesz wysyłać ani odbierać wiadomości push, a odpowiednie sekcje tego dokumentu nie pomagają w debugowaniu problemu, być może znajdziesz błąd w samym mechanizmie wypychania. W takim przypadku zapoznaj się z sekcją Zgłaszanie błędów, aby przygotować dobry raport o błędzie ze wszystkimi niezbędnymi informacjami, które przyspieszą proces naprawiania błędów.

Na początku warto zaznaczyć, że Firefox i usługa Mozilla AutoPush Service zwracają duże komunikaty o błędach. Jeśli napotkasz problem i nie będziesz wiedzieć, na czym polega problem, przetestuj go w Firefoksie i sprawdź, czy wyświetla się bardziej przydatny komunikat o błędzie.

Problemy z autoryzacją

Problemy z autoryzacją to jedne z najczęstszych problemów, z którymi deweloperzy mają do czynienia przy rozpoczynaniu korzystania z Web Push. Zwykle jest to problem z konfiguracją kluczy serwera aplikacji (inaczej kluczy VAPID) witryny.

Najprostszym sposobem na obsługę push zarówno w przeglądarce Firefox, jak i w Chrome, jest podanie identyfikatora applicationServerKey w wywołaniu subscribe(). Wadą jest to, że każda rozbieżność między kluczami interfejsu użytkownika i serwera powoduje błąd autoryzacji.

W Chrome i FCM

W przypadku Chrome, który korzysta z FCM jako usługi push, otrzymasz od FCM odpowiedź UnauthorizedRegistration z różnymi błędami, z których wszystkie dotyczą klucze serwera aplikacji.

Błąd UnauthorizedRegistration wystąpi w każdej z tych sytuacji:

Jeśli nie zdefiniujesz nagłówka Authorization w żądaniu wysyłanym do FCM.
Klucz aplikacji użyty do zasubskrybowania użytkownika nie pasuje do klucza używanego do podpisania nagłówka autoryzacji.
Token JWT nie stracił ważności, tzn. upłynął 24 godziny od jego wygaśnięcia lub ważność JWT już wygasła.
Token JWT ma nieprawidłowy format lub wartości.

Pełna odpowiedź o błędzie wygląda tak:

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

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

Jeśli ten komunikat o błędzie pojawi się w Chrome, spróbuj przetestować w Firefoksie, by sprawdzić, czy pomoże to dokładniej rozwiązać problem.

Firefox i Mozilla AutoPush

Przeglądarki Firefox i Mozilla AutoPush udostępniają przyjazny zestaw komunikatów o błędach w przypadku problemów z Authorization.

Jeśli w żądaniu push nie ma nagłówka Authorization, otrzymasz też odpowiedź o błędzie Unauthorized od 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"
}

Jeśli ważność tokena JWT wygasła, pojawi się też komunikat o błędzie Unauthorized z informacją o wygaśnięciu tokena.

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

Jeśli klucze serwera aplikacji różnią się między datą subskrypcji użytkownika a podpisaniem nagłówka autoryzacji, zostanie zwrócony błąd 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"
}

Jeśli token JWT jest nieprawidłowy (np. wartość „alg” jest nieoczekiwana), Mozilla AutoPush wyświetli następujący błąd:

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

Kody stanów HTTP

Występuje wiele problemów, które mogą powodować występowanie kodu odpowiedzi innego niż 201 z usługi push. Poniżej znajduje się lista kodów stanu HTTP wraz z ich znaczeniem w odniesieniu do funkcji web push.

Kod stanu	Opis
429	Zbyt wiele żądań. Serwer aplikacji osiągnął limit liczby żądań w usłudze push. Odpowiedź z usługi powinna zawierać nagłówek „Retry-After”, który wskazuje, po jakim czasie można wysłać kolejne żądanie.
400	Błędne żądanie. Jeden z nagłówków jest nieprawidłowy lub źle sformatowany.
404	Nie znaleziono. W takim przypadku usuń PushSubscription z backendu i poczekaj na możliwość ponownego wykupienia subskrypcji użytkownika.
410	Brak. Subskrypcja nie jest już aktualna i należy ją usunąć z backendu. Można to odtworzyć, wywołując funkcję „unsubscribe()” w metodzie „PushSubscription”.
413	Zbyt duży rozmiar ładunku. Minimalny rozmiar ładunku, który musi obsługiwać usługa push, to 4096 bajtów (lub 4 KB). Przyczyną tego błędu może być użycie większych elementów.

Jeśli kodu stanu HTTP nie ma na tej liście, a komunikat o błędzie nie jest pomocny, sprawdź specyfikację protokołu Web Push Protocol, aby sprawdzić, czy odwołuje się do niego kod stanu oraz kiedy można go użyć.

Problem z szyfrowaniem ładunku

Jeśli udało Ci się aktywować wiadomość push (tj. wysłać wiadomość do usługi Webpush i otrzymać kod odpowiedzi 201), ale zdarzenie push nie uruchamia się w mechanizmie Service Worker, zwykle oznacza to, że przeglądarka nie odszyfrowała otrzymanej wiadomości.

W takim przypadku w konsoli Narzędzi deweloperskich przeglądarki Firefox powinien wyświetlić się taki komunikat:

Narzędzia deweloperskie w przeglądarce Firefox z komunikatem o odszyfrowywaniu.

Aby sprawdzić, czy na tym polega problem w Chrome, wykonaj te czynności:

Wejdź na about://gcm-internals i kliknij przycisk „Start record” (Rozpocznij nagrywanie).

Rekord wewnętrzny GCM Chrome.

Wywołaj komunikat push i sprawdź „Dziennik błędów odszyfrowywania wiadomości”.

Dziennik odszyfrowywania GCM.

Jeśli wystąpi problem z odszyfrowywaniem ładunku, pojawi się błąd podobny do tego wyświetlanego powyżej. (Zwróć uwagę na komunikat AES-GCM decryption failed w kolumnie szczegółów).

Oto kilka narzędzi, które mogą pomóc w debugowaniu szyfrowania, jeśli to jest Twój problem:

Problem z połączeniem

Jeśli w skrypcie service worker nie otrzymujesz zdarzenia push i nie pojawiają się błędy odszyfrowywania, może to oznaczać, że przeglądarka nie może połączyć się z usługą push.

Aby sprawdzić, czy przeglądarka w Chrome odbiera wiadomości, przejrzyj okno „Odbieraj dziennik wiadomości” w about://gcm-internals.

Użytkownicy wewnętrzni GCM otrzymują dziennik komunikatów.

Jeśli wiadomość nie dotarła na czas, sprawdź, czy stan połączenia przeglądarki to CONNECTED:

Stan połączenia wewnętrznego GCM.

Jeśli to nie„POŁĄCZONO”, konieczne może być usunięcie obecnego profilu i utworzenie nowego. Jeśli to nie rozwiąże problemu, zgłoś błąd, postępując zgodnie z instrukcjami poniżej.

Generowanie raportów o błędach

Jeśli żadne z powyższych rozwiązań nie pomaga i nie wiesz, na czym polega problem, zgłoś problem dotyczący przeglądarki, z którą masz problem:

W przypadku Chrome należy zgłosić ten problem tutaj: https://bugs.chromium.org/p/chromium/issues/list W przypadku przeglądarki Firefox należy zgłosić problem na stronie: https://bugzilla.mozilla.org/

Aby przesłać dobry raport o błędzie, podaj te informacje:

Przeglądarki, w których zdarzyło Ci się przetestować (np. Chrome 50, Chrome 51, Firefox w wersji 50, Firefox w wersji 51).
Przykład PushSubscription pokazujący problem.
Uwzględnij dowolne przykładowe żądania (tj. treść żądań sieciowych wysyłanych do usługi push, wraz z nagłówkami).
Uwzględnij też przykładowe odpowiedzi z żądań sieciowych.

Jeśli możesz podać możliwy do odtworzenia przykład (kod źródłowy lub hostowaną witrynę), często przyspiesza to zdiagnozowanie i rozwiązanie problemu.