בקשות HTTP בלי curl: הטריק של bash /dev/tcp בתוך קונטיינר

מפתח שנדרש לבדוק שקונטיינר אחד מגיע לאחר ברשת Docker פנימית לא מצא את הכלי המתבקש: תמונת האפליקציה הייתה מחוקה עד הסוף ולא כללה curl, wget או כל דרך אחרת לפתוח סוקט. הפתרון, שתועד ברשומה קצרה, נשען על יכולת מובנית של bash — ההתקן המדומה /dev/tcp: המעטפת פותחת בעצמה סוקט TCP, ואת בקשת ה-HTTP כותבים ביד.

בקשת HTTP שנכתבת ביד

הגישה לא דורשת דבר מעבר למעטפת שכבר נמצאת שם. מתאר קובץ נפתח מול היעד — exec 3<>/dev/tcp/service/8642 — ואז printf כותב בקשה מינימלית: שורת הבקשה, כותרת Host וכותרת Connection: close. הפקודה cat <&3 מדפיסה את כל מה שהשרת מחזיר: שורת הסטטוס, הכותרות והגוף. הוספת כותרת Authorization: Bearer היא הוספה של שורה אחת נוספת שמסתיימת ב-CRLF לפני השורה הריקה שסוגרת את הבקשה.

/dev/tcp אינו קובץ אמיתי

מה שהכי מפתיע הוא ש-/dev/tcp לא קיים בדיסק: ls /dev/tcp לא ימצא דבר, ו-cat ממעטפת אחרת ייכשל מיד. זהו הפניה פנימית של bash — המעטפת מבצעת את שאילתת ה-DNS ואת קריאת connect(2), ואז מקצה לסוקט מתאר קובץ. השמות נבחרו דווקא מפני שבשום Unix אמיתי אין היררכיית /dev/tcp, ולכן אין חשש להתנגשות. מכיוון שזו תכונה של bash ולא תקן POSIX, היא לא עובדת ב-dash או ב-zsh, וסקריפט חייב לקרוא ל-bash ישירות.

מה השיטה הזאת לא עושה

המחבר מדגיש שזה אינו לקוח HTTP: הוא לא מפרסר תשובות, לא עוקב אחרי הפניות, לא מטפל בקידוד chunked, בדחיסה, בניסיונות חוזרים או ב-TLS — הסוקט הוא טקסט גלוי בלבד, ולכן ל-https יידרש openssl s_client. אם משמיטים את כותרת Connection: close, השרת ישאיר את החיבור פתוח ו-cat ימתין לנצח לבייטים שלא יגיעו; עטיפה ב-timeout 6 bash -c '...' פותרת זאת. התכונה עצמה נקבעת בזמן קומפילציה (--enable-net-redirections): רוב הבניות המודרניות כוללות אותה, אבל Debian הפציה אותה כבויה במשך שנים. המסקנה לא משתנה — בעבודה יומיומית curl נשאר הכלי הנכון, אבל בקונטיינר מינימלי בכוונה הטריק הזה נותן בדיקה מהירה בלי להתקין חבילות.