מסמך זה חל על השיטות הבאות:
בקשות עדכון
כדי למנוע עומס יתר בשרת וליהנות מהגנה אופטימלית, ב-Update API (v4) מוגדרים מרווחי זמן שבהם הלקוחות יכולים לשלוח בקשות לשרת הגלישה הבטוחה כדי לבצע בדיקות של כתובות URL (fullHashes.find) או כדי לעדכן את מסד הנתונים המקומי (threatListUpdates.fetch).
הבקשה הראשונית לנתונים צריכה להתבצע במרווח אקראי בין 0 ל-1 דקות אחרי שהלקוח מתחיל או מתעורר. הבקשות הבאות יכולות להתרחש רק אחרי שתציינו את מגבלת הזמן של משך ההמתנה המינימלי או של מצב השהיה (back-off).
משך המתנה מינימלי
גם התגובה fullHashes.find וגם התגובה threatListUpdates.fetch כוללים שדה minimumWaitDuration שהלקוחות חייבים לציית לה.
אם השדה minimumWaitDuration לא מוגדר בתגובה, לקוחות יכולים
לעדכן כמה שהם רוצים ולשלוח כמה בקשות threatListUpdates או fullHashes
שהם רוצים.
אם השדה minimumWaitDuration מוגדר בתגובה, לקוחות לא יכולים לעדכן בתדירות גבוהה יותר ממשך ההמתנה. לדוגמה, אם התשובה fullHashes כוללת משך המתנה מינימלי של שעה אחת, הלקוח לא יכול לשלוח בקשות fullHashes עד שהשעה תסתיים, גם אם המשתמש מבקר בכתובת URL שקידומת הגיבוב שלה תואמת למסד הנתונים המקומי. (לתשומת ליבך: לקוחות יכולים לבצע עדכונים בתדירות נמוכה יותר ממשך ההמתנה המינימלי, אבל הדבר עלול להשפיע לרעה על ההגנה).
מצב השהיה
השהיה אוטומטית של הגיבוי חלה גם על התגובה fullHashes.find וגם על התגובה של threatListUpdates.fetch.
לקוחות שמקבלים תגובת HTTP לא מוצלחת (כלומר כל קוד סטטוס HTTP אחר מלבד 200 OK) חייבים להיכנס למצב השהיה (back-off). כשהלקוחות נמצאים במצב השהיה, הם צריכים להמתין למשך הזמן המחושב לפני שיוכלו לשלוח בקשה נוספת לשרת.
לקוחות חייבים להשתמש בנוסחה הבאה כדי לחשב את משך הזמן של השהיית ההשהיה:
MIN((2N-1 * 15 minutes) * (RAND + 1), 24 hours)
N הוא מספר הבקשות הרציפות שלא עברו בהצלחה שהלקוח חווה (מתחיל ב-N=1 אחרי הבקשה הראשונה שנכשלה). RAND הוא מספר אקראי בין 0 ל-1 שיש לבחור אחרי כל עדכון שנכשל.
אחרי שלקוח מקבל תגובת HTTP מוצלחת, הוא צריך לצאת ממצב השהיה לאחור ולפעול בהתאם למשך ההמתנה המינימלי שצוין למעלה.