تصاویر ناقص از طریق پروکسی: پایان نوشتن Netty را بررسی کنید

یک تصویر روی اتصال مستقیم سریع کار می‌کند، اما از طریق یک پروکسی پیشرو کندتر ناقص می‌رسد. یکی از علت‌های ممکن این است که مبدأ اتصال را می‌بندد در حالی که پاسخش هنوز در حال نوشتن است.

ورودی/خروجی Netty ناهمگام است. بازگشت از writeAndFlush به معنای کامل شدن آن عملیات نیست. بنابراین این ترتیب برای پاسخی که هنوز بایت‌های صف‌شده دارد ایمن نیست:

ctx.writeAndFlush(response);
ctx.close();

وقتی تبادل HTTP پس از آخرین پیام پاسخش عمداً بسته می‌شود، بستن را به future همان نوشتن متصل کنید:

ctx.writeAndFlush(finalResponseMessage)
    .addListener(ChannelFutureListener.CLOSE);

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

شکست future را به‌عنوان بخشی از مدیریت خطای معمول برنامه بررسی کنید. اتمام شامل شکست و لغو است، پس اتمام به‌تنهایی رسید تحویل از مرورگر نیست.

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