یک پوشش کوچک پروکسی می‌تواند برای HTTPS کار کند و سپس هنگام استفاده دوباره برای پروتکلی که سرور آن ابتدا صحبت می‌کند معلق بماند. خط مشکوک غالباً همان خطی است که منتظر می‌ماند تا بافر دریافت با \r\n\r\n به پایان برسد.

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

مرز را درون بافر پیدا کنید

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

یک پاسخ 2xx موفق نهایی، اتصال را بلافاصله پس از آن سرآیندها به حالت تونل تبدیل می‌کند. بایت‌های پایانی آن از قبل بایت‌های تونل هستند. آن‌ها را دور نریزید، منتظر بدنه پاسخ CONNECT نمانید، و فیلد Content-Length را مجوز مصرف بخشی از پروتکل جدید تفسیر نکنید. پاسخ‌های اطلاعاتی، اگر وجود داشته باشند، باید پیش از آن پاسخ نهایی مدیریت شوند.

پوشش باید باقی‌مانده‌های خود را تحویل دهد

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

در مقابل، بایت‌های یک پاسخ CONNECT ناموفق سلام تونل نیستند. یک 407 هنوز به تبادل پروکسی تعلق دارد و به رسیدگی احراز هویت نیاز دارد؛ وضعیت ناموفق دیگر به مسیر خطای مناسب نیاز دارد.

این نکته به‌ویژه هنگام سازگار کردن یک مشتری FTP یا SSH از طریق پروکسی HTTP اهمیت دارد. پروکسی همچنین باید پورت مقصد درخواستی را مجاز کند، و FTP ممکن است به اتصال‌های داده اضافی نیاز داشته باشد. تجزیه درست سرآیند انتقال جریان را حل می‌کند؛ نمی‌تواند مجوز CONNECT بدهد یا کانال دوم FTP را فراهم کند.

مقالات مرتبط