NetworkStream.DataAvailable لا يحدد نهاية استجابة HTTP

NetworkStream.DataAvailable == false يعني عدم وجود بايتات جاهزة للقراءة فورًا. وهو لا يعني أن استجابة HTTP اكتملت. والحلقة التي تتوقف عند هذه النقطة قد تقتطع تنزيل SOCKS طبيعيًا تمامًا أثناء فجوة بين الحزم.

بعد أن ينشئ SOCKS اتصال TCP، يظل تأطير HTTP هو الذي يحدد قاعدة الاكتمال:

• ينتهي جسم Content-Length بعد بايتات المحتوى المعلنة.
• تستلزم الاستجابة المُقطّعة (chunked) مقطعها الختامي والـ trailers المنطبقة.
• تنتهي الاستجابة المحددة بالاتصال بانتهاء الاتصال.
• بعض الحالات والاستجابات لطلب HEAD لا تحتوي على جسم.

اقرأ الحالة والترويسات لتحديد القاعدة المنطبقة. وانتظار الإغلاق وحده ليس حلًا عامًا، لأن استجابة HTTP مكتملة قد تترك الاتصال مفتوحًا. وسعة مخزن واحد لا علاقة لها بطول الاستجابة.

استخدم تطبيق التأطير في عميل HTTP عندما يدعم وسيط النقل البروكسي المختار. وعلى وقت تشغيل .NET حديث متوافق، فكّر في دعم SOCKS الأصلي في HttpClient. ويجب على التطبيق الخام أن يحفظ حالة التحليل عبر الترويسات الجزئية وقراءات الجسم، وأن يميّز الاكتمال الناجح عن الإلغاء والمهلة و EOF غير المتوقع. وفي طلب قراءة غير فارغ، يعني صفر بايتات مقروءة أن التدفق انتهى؛ وهذا يختلف عن عدم وجود بايتات في قائمة الانتظار في هذه اللحظة.

قد يجعل البروكسي فجوات التوقيت ملحوظة، لكنه لا يحوّل قائمة استقبال فارغة إلى علامة نهاية رسالة.