הערכת PAC ב-Jint: עוזרים חסרים ותוצאות מסלול

אם Jint מדווח על dnsResolve או myIpAddress חסרים בזמן הערכת PAC, טעינת JavaScript נוסף אינה בהכרח הפתרון. עוזרי PAC אלה שייכים לסביבה שמספקת אפליקציית המארח.

לפני קריאה ל-FindProxyForURL

בחרו את מערך עוזרי ה-PAC הנתמך ואת משפחות הכתובות, ואז התקינו את העוזרים במנוע. שמרו על החוזים שלהם: dnsResolve מקבל שם מארח, myIpAddress אינו מקבל ארגומנטים וזקוק למדיניות ממשק מקומי, ו-shExpMatch משתמש בתבניות בסגנון shell. רכיב דמה שמחזיר ערך נוח עלול לבחור בשקט במסלול הלא נכון.

לאחר שהאתחול הזה נעשה, הקריאה המרכזית יכולה להיראות כך ב-Jint 4.4.0:

var destination = new Uri(destinationUrl);
engine.Execute(pacSource);
var routeList = engine.Invoke(
    "FindProxyForURL",
    destinationUrl,
    destination.IdnHost
).AsString();

engine הוא ה-Jint.Engine המוגדר; pacSource הוא תוכנית ה-PAC שאוחזרה. destination.IdnHost מספק את שם המארח בלי פורט או נתיב. קריאה זו אינה מאחזרת PAC ואינה פותחת חיבור פרוקסי.

אחרי הקריאה

פרשו תוצאה כמו PROXY proxy.example:8080; DIRECT כרשימה מסודרת של מועמדי מסלול וחלופה. העברת המחרוזת כולה ככתובת URL של פרוקסי מאבדת את משמעותה. הפרידו כשל הערכה מתוצאת DIRECT מפורשת.

בזמן הריצה

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

מימושים של PAC בדפדפנים עשויים להיבדל בהרחבות עוזרים ובפרטי ה-URL שהם חושפים, במיוחד ל-HTTPS. התאמה לתוצאת דוגמה אחת מוכיחה פחות מהתאמה להתנהגות הניתוב של הדפדפן.