שורת הבקשה שמנתבת HTTP של Node דרך פרוקסי

בבקשת HTTP רגילה דרך פרוקסי קדמי, Node מתחבר לפרוקסי ושולח את כתובת היעד בשורת הבקשה. שלושה ערכים מתארים את הבקשה האחת הזו:

הדוגמה הזו ל-Node 22 מבהירה את ההפרדה:

const http = require('node:http');
const destination = new URL('http://example.com/news?q=proxy');

const request = http.get({
  hostname: 'proxy.example',
  port: 8080,
  path: destination.href,
  headers: { Host: destination.host },
  signal: AbortSignal.timeout(15000),
}, (response) => {
  console.log(response.statusCode);
  response.on('error', console.error);
  response.resume();
});
request.on('error', console.error);

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

מדוע הכתובת המלאה שייכת לשם

שרת מקור מקבל בדרך כלל יעד כמו /news?q=proxy. פרוקסי קדמי זקוק גם ליעד, ולכן HTTP/1.1 מגדיר את היעד בצורה מוחלטת:

GET http://example.com/news?q=proxy HTTP/1.1
Host: example.com

לפי כללי HTTP/1.1, פרוקסי שמקבל צורה מוחלטת משתמש בסמכות של ה-URI בעת העברה ומחליף שדה Host שהתקבל ואינו עקבי. שליחת כותרת Host עקבית של היעד עדיין משאירה את הבקשה היוצאת חד-משמעית. שם המארח של החיבור ב-Node הוא המתווך, לכן הגדירו את הכותרת במכוון במקום להסתמך על כתובת החיבור הזו.

אם נדרש אימות, פרטי הפרוקסי שייכים לקפיצה שלו. אפשרות הבקשה auth של Node יוצרת כותרת Authorization עבור המשאב; זו אינה אפשרות התחברות כללית לפרוקסי. השתמשו בסכימה שהפרוקסי דורש ובלקוח פרוקסי מתאים כאשר ההחלפה מורכבת יותר.

HTTPS מוסיף מנהרה

הדוגמה הזו מכסה העברת HTTP פשוטה. חיבור HTTPS דרך פרוקסי HTTP טיפוסי מבקש תחילה CONNECT example.com:443, ואז מתחיל TLS אל היעד בתוך המנהרה שהתקבלה. שינוי כתובת הדוגמה ל-HTTPS אינו מוסיף את השלבים האלה.

עבור HTTPS או עומס מעורב, השתמשו בסוכן פרוקסי או בשליח מתוחזק עם תמיכת המנהרה הנדרשת. עבור גרסאות Node תואמות, אפשרות אחת היא fetch של Undici עם ProxyAgent. שמרו את הדוגמה הקטנה הזו של לקוח הליבה למקרים שבהם החלפת ה-HTTP הפשוטה עצמה היא מה שאתם צריכים לשלוט בו או להבין.