جب ڈاؤن لوڈ کی گئی فائل HTTP اسٹیٹس لائن سے شروع ہو

اگر PDF یا اسپریڈ شیٹ سمجھی جانے والی فائل HTTP/1.1 200 OK سے شروع ہوتی ہے تو ڈاؤن لوڈر نے فائل کے بجائے خام جواب محفوظ کیا ہے۔ اس خاکہ جواب میں صرف چار بائٹ مواد ہے:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

فائل DATA ہے۔ اسٹیٹس لائن، ہیڈر، سائز مارکر اور اختتامی ساخت HTTP کی ہیں۔ ہیڈر کی لمبائی مختلف ہونے کی وجہ سے مقررہ تعداد میں بائٹ ہٹانا محفوظ نہیں۔ پہلی خالی لائن کے بعد سب کچھ کاپی کرنے پر بھی چنک فریمنگ رہ جاتی ہے، اور معلوماتی جواب حتمی جواب سے پہلے آ سکتے ہیں۔

عام ڈاؤن لوڈ کے لیے خام ساکٹ سے فائل میں کاپی کرنے کو HTTP کلائنٹ کے جوابی باڈی انٹرفیس سے بدلیں۔ اس کا پراکسی کنفیگر کریں، حتمی اسٹیٹس کی تصدیق کریں اور باڈی کو عارضی آؤٹ پٹ میں اسٹریم کریں۔ کلائنٹ پیغام کی فریمنگ سنبھالتا ہے: لمبائی سے محدود، چنکڈ اور کنکشن سے محدود باڈیوں کے لیے مختلف پارسنگ درکار ہے۔

مواد کی انکوڈنگ ایک اور تہہ ہے۔ کلائنٹ کے دستاویزی رویے کو استعمال کرتے ہوئے فیصلہ کریں کہ آپ کو ڈی کوڈ شدہ فائل بائٹس چاہیے یا واضح طور پر مانگی گئی خام مواد۔ کمپریس شدہ بائٹ خود بخود پراکسی کی خرابی نہیں۔

اگر ایپلیکیشن کو ساکٹ سطح کا کوڈ رکھنا ہی ہے تو ان تمام پارسنگ قواعد اور پڑھنے لکھنے کی ذمہ داری اسی کی ہے۔ بفر کی گنجائش نہیں بلکہ پڑھنے سے واقعی واپس ملنے والے بائٹس کی تعداد لکھیں، اور جزوی لکھائی سنبھالیں۔ ورنہ پرانا بفر مواد صحیح طور پر نکالی گئی باڈی کو بھی خراب کر سکتا ہے۔

HTTPS کو CONNECT جواب ہٹانے سے زیادہ کی ضرورت ہے: سرنگ کامیابی سے قائم ہونے کے بعد منزل کا TLS قائم کریں اور پھر اندرونی HTTP جواب پارس کریں۔ پراکسی کے ہیڈروں کے بعد آنے والے خفیہ بائٹس ڈاؤن لوڈ کے قابل فائل نہیں۔

ناکام یا نامکمل آؤٹ پٹ کو عارضی نام کے تحت رکھیں۔ منتقلی اور فائل جانچ کامیاب ہونے کے بعد ہی اسے شائع کریں؛ خالی نہ ہونے والی فائل مکمل ڈاؤن لوڈ ثابت نہیں کرتی۔