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

רמז שימושי נמצא ביומן הגישה של שרת האינטרנט: הלקוח ביקש /wpad.dat וקיבל HTTP 404. כתובת PAC שנפתחת ידנית עשויה להשתמש בשם מארח אחר. גם כששני השמות מגיעים לאותו שרת, הם עשויים לבחור מארחים וירטואליים שונים.

עקבו אחר הבקשה שהלקוח שלח

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

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

הגישו סקריפט, לא עמוד שגיאה

אמתו את גוף התגובה וגם את סטטוסה. עמוד התחברות, מסמך שגיאה ממותג או הפניה מחדש עשויים להיראות סבירים בבדיקה ידנית, אך אינם סקריפט ה-PAC שהפותֵר מצפה לו. Chromium מתעד דרישות הורדת PAC מחמירים, כולל תגובת HTTP 200.

רק לאחר המסירה תצליח יש טעם לנפות באגים ב-FindProxyForURL(). שינוי כללי שמות המארח שלו אינו יכול לתקן 404 שמנע מהדפדפן להשיג אותו.

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

מאמרים קשורים