بدنه‌های POST در پروکسی HTTP پایتون می‌توانند در rfile بافر شوند

پروکسی پیش‌رو خط درخواست و سرایندها را می‌خواند، آن‌ها را ارسال می‌کند و سپس در select منتظر بدنهٔ POST می‌ماند. کلاینت آن را پیش‌تر فرستاده است. به نظر می‌رسد هر دو طرف منتظر یکدیگرند.

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

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

بدنه را هم از self.rfile بخوانید. پس از تجزیهٔ سرایندها با جریان بافرشده به self.connection.recv سوئیچ نکنید. وگرنه کد می‌تواند بایت‌هایی را که آن جریان نگه داشته دور بزند و منتظر داده‌ای بماند که هرگز دوباره فرستاده نمی‌شود.

سپردن خود rfile به select باعث نمی‌شود select بافر پایتونی آن را بررسی کند. API آمادگی از طریق توصیفگر فایل شیء کار می‌کند.

برای درخواستی با یک Content-Length معتبر و بدون Transfer-Encoding، دقیقاً همان تعداد بایت اعلام‌شده را مصرف کنید و پایان زودهنگام ورودی و محدودیت‌های اندازه و زمان خود را مدیریت کنید. تا EOF نخوانید: کلاینتی که از اتصال پایدار استفاده می‌کند ممکن است اتصال را پس از پایان درخواست باز نگه دارد.

قاب‌بندی را بخشی صریح از پروکسی کنید

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

هندلر مسدودکننده می‌تواند به استفاده از رابط جریان خود با خواندن‌های محدود ادامه دهد. پروکسی رویدادمحور به مدل بافری نیاز دارد که خواندن پیش‌روی تجزیه‌گر را با مدیریت آمادگی یکپارچه کند. تغییر یک مهلت زمانی دو مصرف‌کنندهٔ مستقل یک سوکت را آشتی نمی‌دهد.

این تشخیص مشخص می‌کند بایت‌های ورودی کجا نگه داشته می‌شوند. پس از آنکه پروکسی بدنهٔ درست را مصرف کرد، باز هم باید آن بدنه را با قاب‌بندی HTTP سازگار ارسال کند. هندلر استاندارد http.server جای مفیدی برای فهم سازوکار است، اما پیاده‌سازی پروکسی پیش‌رو برای تولید نیست.