עבור ידית libcurl קיימת, הפרידו באופן מפורש את רשימות כותרות היעד וה-proxy:

curl_easy_setopt(handle, CURLOPT_HEADEROPT, (long)CURLHEADER_SEPARATE);
curl_easy_setopt(handle, CURLOPT_PROXYHEADER, proxy_headers);
curl_easy_setopt(handle, CURLOPT_HTTPHEADER, origin_headers);

השאירו את הידית המוגדרת ואת הרשימות התקפות בחיים במהלך ההעברה. CURLHEADER_SEPARATE מבדיל בין כותרות המשמשות ב-CONNECT לבין כותרות המשמשות לבקשת היעד. דוגמאות ישנות של מדיניות מאוחדת יכולות לשים את הרשימה הרגילה בשני חילופי הדברים.

נתיב הבקשהמשמעות הרשימות הנפרדות
HTTPS בתוך מנהרת CONNECT רגילהחילופי ה-proxy באים תחילה; לאחר מכן כותרות ה-HTTP של היעד מגיעות בתוך ה-TLS של היעד.
העברת HTTP פשוטהה-proxy יכול לקרוא את כותרות היעד, ו-libcurl יכול להשתמש בשתי הרשימות הרלוונטיות בבקשת ההעברה האחת.

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

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

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

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