یک report.xlsx فرضی 8 KB است و به صورت صفحه ورود باز می‌شود. برنامه فایلی را با موفقیت ذخیره کرد، اما هرگز صفحه‌گسترده مورد نظر را به دست نیاورد. نام فایل به صورت محلی انتخاب می‌شود؛ مدرکی بر آنچه رسیده نیست.

پذیرش را پیش از انتشار دانلود موقت به مرحله‌ای جداگانه تبدیل کنید:

  1. انتقال موفق و وضعیت پاسخ مورد انتظار را الزامی کنید. خطا را نگه دارید، نه اینکه بایت‌های نوشته‌شده پیش از آن را کامل بدانید.
  2. محتوا را با نوع فایل مورد انتظار مقایسه کنید. صفحه ورود یا فیلتر ممکن است 200 برگرداند. Content-Type می‌تواند نادرست باشد، و پیشوند HTML در یک صفحه‌گسترده هشداری است که نیاز به بررسی دارد. فایلی که با خط وضعیت HTTP شروع می‌شود، در عوض به قالب‌بندی پاسخ خام اشاره دارد.
  3. کل بایت‌های ذخیره‌شده را در صورت وجود با یک چک‌سام یا امضای مورد اعتماد اعتبارسنجی کنید. برنامه تنها پس از گذراندن بررسی‌های لازم باید فایل نهایی را منتشر کند یا به کار ببرد.

محاسبه هش بدون مقدار مورد انتظار تنها بایت‌هایی را که دریافت کرده‌اید مشخص می‌کند. چک‌سام بدون امضایی که از همان مسیر غیرقابل اعتماد گرفته شود می‌تواند ضعف فایل را به اشتراک بگذارد؛ از انتظار مورد اعتماد مستقل استفاده کنید.

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

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

مقالات مرتبط