NetworkStream.DataAvailable پایان یک پاسخ HTTP را مشخص نمی‌کند

NetworkStream.DataAvailable == false یعنی هیچ بایتی برای خواندن فوری آماده نیست. این به معنای کامل شدن پاسخ HTTP نیست. حلقه‌ای که آنجا متوقف شود می‌تواند در فاصله میان بسته‌ها یک دانلود کاملاً عادی SOCKS را قطع کند.

پس از آنکه SOCKS اتصال TCP را برقرار کرد، قاب‌بندی HTTP همچنان قاعده تکمیل را تعیین می‌کند:

• بدنه با Content-Length پس از بایت‌های محتوای اعلام‌شده پایان می‌یابد.
• پاسخ chunked به chunk پایانی و trailerهای مربوط نیاز دارد.
• پاسخی که با اتصال محدود شده، با اتصال پایان می‌یابد.
• برخی وضعیت‌ها و پاسخ‌ها به HEAD بدنه ندارند.

وضعیت و سرآیندها را بخوانید تا قاعده قابل اعمال را تعیین کنید. انتظار فقط برای بسته شدن راه‌حل عمومی نیست، زیرا یک پاسخ کامل HTTP می‌تواند اتصال را باز بگذارد. ظرفیت یک بافر نیز به همان اندازه به طول پاسخ بی‌ربط است.

وقتی کلاینت HTTP از انتقال پروکسی انتخاب‌شده پشتیبانی می‌کند، از پیاده‌سازی قاب‌بندی آن استفاده کنید. روی یک رانتایم مدرن سازگار .NET، پشتیبانی بومی SOCKS در HttpClient را در نظر بگیرید. پیاده‌سازی خام باید وضعیت تجزیه را در سرآیندهای جزئی و خواندن‌های بدنه حفظ کند و تکمیل موفق را از لغو، پایان مهلت و EOF غیرمنتظره جدا کند. در درخواست خواندن غیرخالی، صفر بایت خوانده‌شده یعنی جریان پایان یافته است؛ این با نبودن بایت در صف در همین لحظه تفاوت دارد.

پروکسی می‌تواند فاصله‌های زمانی را نمایان کند، اما صف دریافت خالی را به نشانه پایان پیام تبدیل نمی‌کند.