WSS דרך Squid אינו זהה לשדרוג WebSocket רגיל
הפרידו בין WebSocket מוצפן בתוך CONNECT לבין טיפול ב-HTTP Upgrade בטקסט גלוי בפרוקסי קדמי.
האם Squid רואה בקשת HTTP Upgrade, או רק מנהרה הנושאת תעבורה מוצפנת? זה קובע אם בקרות ה-HTTP Upgrade שלו מטפלות בכשל.
| מסלול פרוקסי מפורש רגיל | מה Squid פוגש |
|---|---|
wss:// | בדרך כלל CONNECT, ואחריו TLS של היעד הנושא את לחיצת היד של WebSocket |
ws:// | בקשת HTTP Upgrade בטקסט גלוי שהפרוקסי יכול לעבד |
בקרת השדרוג של Squid נוגעת לבקשות שהוא מעבד. היא אינה חושפת כותרות HTTP מוצפנות בתוך מנהרת WSS אטומה רגילה. יירוט TLS או טיפול פרוקסי מיוחד אחר משנים את הנראות ועלולים להוסיף דרישות תאימות משלהם.
עבור WSS, מצאו היכן הרצף נעצר: חיבור לפרוקסי, CONNECT שהתקבל, TLS מאומת, ואז לחיצת היד של היישום. דחייה לפני TLS היא כשל שונה מבקשת Upgrade בטקסט גלוי שנדחתה.
אם נדרש שינוי במדיניות השדרוג, השתמשו בהנחיה של גרסת Squid המותקנת והתירו את ההתנהגות הנדרשת במפורש. התרה של כל פרוטוקולי השדרוג מרחיבה את המדיניות מעבר ליישום המסוים.
בקשת עמוד HTTPS מוצלחת מבססת רק חלק מהמסלול. תעבורת WebSocket ארוכת טווח עדיין עלולה להיכשל בגלל דרישות היישום, משך החיבור או מגבלות מתווכים, אפילו עבור אותו שם מארח.