WPAD פועל. מדוע כתובת ה-proxy של WinHTTP ריקה?
קריאת תצורת ה-proxy של Windows ופתרון proxy עבור יעד הן פעולות נפרדות. זהות השירות מוסיפה גבול נוסף.
גילוי proxy אוטומטי יכול להיות מופעל בעוד שמחרוזת ה-proxy הידנית ריקה. WinHttpGetIEProxyConfigForCurrentUser() מחזירה שדות תצורה, ולא נקודת קצה סופית לכל יעד.
| שדה | משמעות |
|---|---|
| Proxy ידני | ערך שהוגדר במפורש |
| כתובת URL של תצורה אוטומטית | מיקום סקריפט ה-PAC |
| דגל גילוי אוטומטי | האם הגילוי מופעל |
המבנה הוא פלט. הגדרת חבר הגילוי האוטומטי שלו לפני קריאת הפונקציה אינה מפעילה את הגילוי של Windows. השתמשו בשדות שהוחזרו כדי לבנות בקשת proxy אוטומטית נפרדת עם הדגלים המתועדים.
קודם לפתור, אחר כך להחיל
API כמו WinHttpGetProxyForUrl() מעריך את כתובת ה-URL האמיתית של היעד. ספקו את הכתובת הזו, ולא את כתובת הורדת ה-PAC, והחילו את תוצאת הפתרון על בקשת ה-WinHTTP הרלוונטית.
תוצאה ישירה תקפה. שגיאות הורדת סקריפט, הערכת סקריפט וחיבור ל-proxy מתרחשות בשלבים נפרדים. בדקו קודי כשל ופעלו לפי כללי הבעלות על המחרוזות המוחזרות.
של מי התצורה?
“CurrentUser” פירושו ההקשר של הקורא. שירות ללא התחזות מתאימה עלול לקרוא את ההגדרות של חשבון השירות שלו במקום את אלה של משתמש שולחן העבודה.
בחרו במודע אם השירות משתמש בהגדרות מנוהלות או פועל לפי התצורה של משתמש מורשה, כולל ההתנהגות כאשר אין משתמש אינטראקטיבי. טיפול באסימונים וניקוי משאבים חייבים לפעול לפי ממשקי ה-API הנתמכים לזהות.
לצורך אבחון, החזיקו יחד את חשבון הקורא, שדות התצורה, היעד, תוצאת הפתרון ושגיאת החיבור הראשונה. זה מראה באיזה שלב נוצר הערך הריק או המסלול הכושל.