پاسخ نهایی FTP را پیش از اعتماد به یک بارگذاری بررسی کنید

یک کلاینت FTP می‌تواند فرمان put را مدت‌ها پیش از آنکه سرور فایل را دریافت کند بپذیرد، و فاصله میان این دو رویداد جایی است که بیشتر رازهای بارگذاری در آن زندگی می‌کند. چهار مرحله باید کامل شود: فایل محلی خوانده می‌شود، سرور درخواست ذخیره‌سازی را می‌پذیرد، اتصال داده بایت‌ها را حمل می‌کند و انتقال به یک پاسخ مثبت نهایی می‌رسد. مقایسه مرحله‌ها از مقایسه کلاینت‌ها سودمندتر است، زیرا ورودی که کار می‌کند و نام فایلی که ظاهر می‌شود هر دو پیش از خط پایان متوقف می‌شوند.

پاسخ مقدماتی در برابر پاسخ نهایی

برای STOR، پاسخ 125 یا 150 مقدماتی است. می‌گوید سرور آماده تلاش است و اتصال داده باز می‌شود، نه اینکه شیء در شکل نهایی خود وجود دارد. عملیات تنها زمانی کامل می‌شود که انتقال در بافت همان عملیات به پاسخ مثبت تکمیل، معمولاً 226 یا 250، برسد.

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

اتصال کنترل در برابر اتصال داده

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

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

FTP روی TLS در برابر SFTP

FTP روی TLS هنوز FTP است: دو اتصال، پاسخ‌های FTP و یک ارتقای TLS روی هر کدام. SFTP زیرسیستمی از SSH با یک اتصال و مجموعه فرمان‌های کاملاً متفاوت است. آن‌ها یک هدف و تقریباً هیچ چیز دیگری را شریک نیستند، بنابراین تشخیصی که میان آن دو جابه‌جا می‌شود معمولاً با مقایسه گزارش‌های اشتباه آغاز می‌گردد.

TLS را غیرفعال نکنید تا یک کمک‌کننده میانی نشست را بازرسی کند، و شکست SFTP را مشکل پاسخ‌های FTP ندانید. راهنمای curl اگر به آزمون اسکریپتی نیاز دارید TLS صریح، حالت غیرفعال و گزینه‌های بارگذاری را مستند می‌کند، و مرجع این است که هر پرچم در واقع چه چیزی را تغییر می‌دهد.

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

نام فایل قابل مشاهده در برابر شیء ذخیره‌شده

نام فایل قابل مشاهده می‌تواند شیئی ناقص را نشان دهد، به‌ویژه پس از انتقالی لغوشده یا کلاینتی که زودتر خارج شده است. از مالک سرویس بخواهید وقتی حفظ بایت‌ها انتظار می‌رود، اندازه فایل آزمایشی مورد نظر و هش محتوای مورد اعتماد را با شیء ذخیره‌شده مقایسه کند.

حالت دودویی و ASCII مقایسه دیگری است که نتیجه را تغییر می‌دهد. حالت ASCII می‌تواند پایان خطوط را ترجمه کند، بنابراین بایت‌های ذخیره‌شده با فایل محلی تفاوت دارند هرچند انتقال موفق بوده است. برای بررسی بایت‌به‌بایت حالت دودویی را نگه دارید و گزینه‌های تبدیل را اضافه نکنید تا انتقالی ناموفق متفاوت به نظر برسد.

یک STOR معمولی می‌تواند فایل موجود را جایگزین کند، و مجوز ورود یا فهرست کردن یک دایرکتوری مجوز ایجاد یا جایگزینی شیئی در آن را ثابت نمی‌کند. برای آزمون از نامی راه دور استفاده کنید که پیش‌تر به کار نرفته است.

پیش از تلاش دوباره چه چیزی را مقایسه کنیم

بارگذاری را کورکورانه به فایلی نیمه‌کاره و نامطمئن الحاق، ادامه یا تکرار نکنید. با مالک به توافق برسید که آیا با نامی تازه از نو آغاز کنید، از رویه بازیابی پشتیبانی‌شده سرویس استفاده کنید، یا شیء آزمایشی ناموفق را حذف کنید.

نتیجه را به عنوان یکی از چهار گزاره بنویسید: خواندن محلی شکست خورد، ذخیره‌سازی رد شد، انتقال داده لغو شد، یا انتقال کامل شد و بایت‌های ذخیره‌شده مطابقت داشتند. این ثبت نتیجه‌ای قوی‌تر از تغییر همزمان پوسته، VPN و تنظیمات FTP تا زمانی است که نام فایلی ظاهر شود، و به نفر بعدی می‌گوید کدام مرحله را بررسی کند. متن پاک‌سازی‌شده پاسخ را همراه آن گزاره نگه دارید. آنگاه تلاش دوباره یک تصمیم است، نه یک واکنش.