طلبات 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 يبقى الأداة الصحيحة للعمل اليومي، لكن داخل حاوية صغيرة عن قصد تنجز هذه الحيلة فحصًا سريعًا من دون تثبيت أي حزمة.