תרגום בקשת SOCKS5 למנהרת HTTP

חזית SOCKS5 יכולה להשתמש בפרוקסי HTTP כשינוע ההמשך שלה. היא פועלת כשרת SOCKS כלפי הלקוח וכמלקוח HTTP CONNECT כלפי האב. שני חילופי השליטה מסתיימים לפני שזרם היישום מתחיל.

בקשת SOCKS CONNECT כבר מספקת את מארח או כתובת היעד ואת הפורט. להמחשת חילופי HTTP/1.1 עם האב:

client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
    CONNECT service.example.net:443 HTTP/1.1
    Host: service.example.net:443

parent → adapter: HTTP/1.1 200 Connection Established
                 [end of headers]
adapter → client: SOCKS5 success reply

client ↔ adapter ↔ parent ↔ service: application bytes

תרגמו את התוצאה בגבול

המתאם משלים כל אימות נדרש אצל האב וממתין לתוצאת ה-CONNECT. תגובת 2xx מוצלחת מבססת את מנהרת האב. רק לאחר מכן עליו להחזיר את תגובת ההצלחה המתאימה של SOCKS ללקוח שבמורד הזרם.

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

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

שמרו את הבייטים שאחרי הכותרות

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

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