דף זה תורגם על ידי Cloud Translation API.

בעיות נפוצות ובאגים בדיווח

Matt Gaunt

אם נתקלת בבעיה ב-Web Push, יכול להיות שיהיה קשה לנפות את הבאגים או למצוא עזרה. במסמך הזה מפורטות כמה מהבעיות הנפוצות, ואנחנו מסבירים מה צריך לעשות אם מצאתם באג ב-Chrome או ב-Firefox.

לפני שנתעמק בדחיפה לניפוי באגים, יכול להיות שתיתקלו בבעיות שקשורות לעובדי השירות לניפוי באגים, שהקובץ לא מתעדכן, לא נרשם או בדרך כלל התנהגות חריגה. יש שם מסמך מדהים בנושא עובדי שירות לניפוי באגים, שמומלץ מאוד לבדוק אם אתם חדשים בתחום הפיתוח של קובצי שירות.

יש שני שלבים נפרדים שצריך לבדוק במהלך הפיתוח והבדיקה של התראות דחיפה לאינטרנט, לכל אחד מהם יש קבוצה משלו של בעיות נפוצות:

שליחת הודעה: מוודאים ששליחת ההודעות בוצעה בהצלחה. אמור להופיע קוד HTTP 201. אם לא:
- בודקים אם יש שגיאות הרשאה: אם מקבלים הודעת שגיאה בהרשאה, עיינו בקטע בעיות בהרשאות.
- שגיאות אחרות ב-API: אם מקבלים תגובה עם קוד סטטוס שאינו 201, אפשר לעיין בקטע קודי סטטוס HTTP כדי לקבל הנחיות לגבי הגורם לבעיה.
קבלת הודעה: אם אתם מצליחים לשלוח הודעה אבל היא לא מתקבלת בדפדפן:
- בדיקת בעיות בהצפנה: עיינו בקטע בדיקת בעיות בהצפנת מטען נתונים.
- בודקים אם יש בעיות בחיבור: אם הבעיה ב-Chrome, יכול להיות שמדובר בבעיה בחיבור. מידע נוסף זמין בקטע בנושא בעיות בחיבור.

אם אתם לא מצליחים לשלוח ולקבל הודעה בדחיפה והקטעים הרלוונטיים במסמך הזה לא עוזרים לנפות את הבאגים, יכול להיות שמצאתם באג במנגנון הדחיפה עצמו. במקרה כזה, כדאי לעיין בקטע דיווח על באגים כדי לשלוח דוח באגים טוב עם כל המידע הנדרש כדי לזרז את תהליך תיקון הבאג.

דבר אחד שאני רוצה לציין לפני שנתחיל הוא שב-Firefox ובשירות AutoPush של Mozilla מוצגות הודעות שגיאה מצוינות. אם נתקעים ולא בטוחים מה הבעיה, אפשר לבדוק ב-Firefox אם מופיעה הודעת שגיאה מועילה יותר.

בעיות שקשורות להרשאות

בעיות הרשאה הן אחת מהבעיות הנפוצות ביותר שמפתחים נתקלים בהן כשהם מתחילים להשתמש ב-Web Push. בדרך כלל זו בעיה בהגדרה של מפתחות שרת אפליקציות (שנקראים גם מפתחות VAPID) באתר.

הדרך הקלה ביותר לתמוך ב-push גם ב-Firefox וגם ב-Chrome היא לספק applicationServerKey בקריאה ל-subscribe(). החיסרון הוא שכל אי-התאמה בין המפתחות של ממשק הקצה לבין המפתחות של השרת תגרום לשגיאת הרשאה.

ב-Chrome וב-FCM

ב-Chrome, שמשתמש ב-FCM בתור שירות Push, מקבלים תשובת UnauthorizedRegistration מ-FCM לגבי מגוון שגיאות שונות, שכולן קשורות למפתחות של שרת האפליקציות.

השגיאה UnauthorizedRegistration תופיע בכל אחד מהמצבים הבאים:

אם לא מגדירים כותרת Authorization בבקשה ל-FCM.
מפתח האפליקציה ששימש להרשמה של המשתמש לא תואם למפתח ששימש לחתימה על כותרת 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.

תקבלו גם תשובה עם השגיאה Unauthorized מ-Mozilla AutoPush אם הכותרת Authorization לא כלולה בבקשת ה-push.

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

אם מפתחות שרת האפליקציה שונים בין המועד שבו המשתמש נרשם לבין המועד שבו כותרת ההרשאה חתומה, תוחזר שגיאה מסוג 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	נעלם. המינוי כבר לא בתוקף וצריך להסיר אותו מהקצה העורפי. אפשר לשחזר את הבעיה על ידי קריאה ל-unsubscribe()‎ ב-PushSubscription.
413	גודל המטען הייעודי גדול מדי. שירות דחיפה חייב לתמוך בגודל מינימלי של עומס שימושי של 4096 בייטים (או 4KB). כל גודל גדול יותר עלול לגרום לשגיאה הזו.

אם קוד סטטוס ה-HTTP לא מופיע ברשימה הזו והודעת השגיאה לא מועילה, כדאי לבדוק במפרט של פרוטוקול Web Push Protocol אם יש הפניה לקוד הסטטוס, יחד עם תרחיש מתי אפשר להשתמש בקוד הסטטוס הזה.

בעיה בהצפנת מטען נתונים

אם אתם מצליחים להפעיל הודעת דחיפה (כלומר, שולחים הודעה לשירות דחיפה לאינטרנט ומקבלים קוד תגובה 201), אבל אירוע הדחיפה אף פעם לא מופעל ב-service worker, בדרך כלל המשמעות היא שהדפדפן לא הצליח לפענח את ההודעה שהוא קיבל.

במקרה כזה, אמורה להופיע הודעת שגיאה במסוף DevTools של Firefox, באופן הבא:

כלי פיתוח ל-Firefox עם הודעת פענוח.

כדי לבדוק אם זו הבעיה ב-Chrome:

עוברים אל about://gcm-internals ולוחצים על הלחצן 'התחלת ההקלטה'.

רשומה של נתונים פנימיים של GCM ב-Chrome.

מפעילים הודעת דחיפה ומחפשים בקטע 'יומן כשלים של פענוח הודעות'.

יומן פענוח של רכיבים פנימיים של GCM.

אם יש בעיה בפענוח של עומס העבודה, תוצג הודעת שגיאה שדומה לזו שמוצגת למעלה. (שימו לב להודעה AES-GCM decryption failed בעמודת הפרטים).

אם זו הבעיה, יש כמה כלים שיכולים לעזור לנפות באגים בהצפנה:

בעיה בחיבור

אם לא מתקבל אירוע דחיפה ב-service worker ואין שגיאות פענוח, יכול להיות שהדפדפן לא מצליח להתחבר לשירות דחיפה.

ב-Chrome, אפשר לבדוק אם הדפדפן מקבל הודעות על ידי בדיקת יומן קבלת ההודעות (sic) בקטע about://gcm-internals.

רכיבים פנימיים של GCM מקבלים יומן הודעות.

אם ההודעה לא מופיעה בזמן, צריך לוודא שסטטוס החיבור של הדפדפן הוא CONNECTED:

מצב החיבור של הרכיבים הפנימיים של GCM.

אם סטטוס הפרופיל לא 'מחובר', יכול להיות שתצטרכו למחוק את הפרופיל הנוכחי שלכם וליצור פרופיל חדש. אם הבעיה לא נפתרה, אפשר לשלוח דוח באג כפי שמתואר בהמשך.

הגדלת דוחות על באגים

אם אף אחת מהאפשרויות שלמעלה לא עזרה לך לפתור את הבעיה ואין סימן לבעיה, עליך לדווח על הבעיה בדפדפן שבו היא מתרחשת:

ב-Chrome, צריך לדווח על הבעיה כאן: https://bugs.chromium.org/p/chromium/issues/list ב-Firefox, צריך לדווח על הבעיה כאן: https://bugzilla.mozilla.org/

כדי לשלוח דיווח טוב על באג, צריך לספק את הפרטים הבאים:

דפדפנים שבדקתם (למשל: Chrome גרסה 50, Chrome גרסה 51, Firefox גרסה 50, Firefox גרסה 51).
דוגמה PushSubscription שממחישה את הבעיה.
יש לכלול בקשות לדוגמה (כלומר, תוכן של בקשות רשת לשירות דחיפה, כולל כותרות).
כדאי לכלול גם דוגמאות לתשובות מבקשות רשת.

אם יש לכם דוגמה שאפשר לשחזר, בין אם מדובר בקוד מקור או באתר אינטרנט מתארח, לרוב זה מאיץ את תהליך האבחון והפתרון של הבעיה.