ایک فرضی report.xlsx 8 KB ہے اور لاگ اِن صفحہ کی طرح کھلتا ہے۔ پروگرام نے فائل کامیابی سے محفوظ کی، مگر مطلوبہ اسپریڈ شیٹ کبھی نہ ملی۔ فائل کا نام مقامی طور پر چنا جاتا ہے؛ یہ ثبوت نہیں کہ کیا آیا۔

عارضی ڈاؤن لوڈ شائع کرنے سے پہلے قبولیت کو الگ مرحلہ بنائیں:

  1. کامیاب منتقلی اور متوقع جواب کی حالت کا تقاضا کریں۔ اس سے پہلے لکھے گئے بائٹس کو مکمل ماننے کے بجائے خرابی محفوظ رکھیں۔
  2. مواد کا متوقع فائل قسم سے موازنہ کریں۔ لاگ اِن یا فلٹر صفحہ 200 واپس کر سکتا ہے۔ Content-Type غلط ہو سکتا ہے، اور اسپریڈ شیٹ میں HTML سابقہ ایک انتباہ ہے جس کی تحقیق ضروری ہے۔ HTTP اسٹیٹس لائن سے شروع ہونے والی فائل اس کے بجائے خام جواب کی فریمنگ کی طرف اشارہ کرتی ہے۔
  3. دستیاب ہونے پر محفوظ شدہ تمام بائٹس کو قابلِ اعتماد چیک سم یا دستخط سے تصدیق کریں۔ ایپلیکیشن کو حتمی فائل صرف مطلوبہ جانچ پاس ہونے کے بعد شائع یا استعمال کرنی چاہیے۔

متوقع قدر کے بغیر ہیش شمار کرنا صرف وہ بائٹس شناخت کرتا ہے جو آپ کو ملے۔ اسی ناقابلِ اعتماد راستے سے حاصل کردہ غیر دستخط شدہ چیک سم فائل کی کمزوری میں شریک ہو سکتا ہے؛ آزاد قابلِ اعتماد توقع استعمال کریں۔

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

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

متعلقہ مضامین