Kiểm tra phản hồi FTP cuối cùng trước khi tin vào một lần tải lên

Một máy khách FTP có thể chấp nhận lệnh put rất lâu trước khi máy chủ nhận được tệp, và khoảng trống giữa hai sự kiện đó chính là nơi trú ngụ của phần lớn bí ẩn khi tải lên. Bốn giai đoạn phải hoàn tất: tệp cục bộ được đọc, máy chủ chấp nhận yêu cầu lưu trữ, kết nối dữ liệu mang các byte, và quá trình truyền đạt tới một phản hồi tích cực cuối cùng. So sánh các giai đoạn hữu ích hơn so sánh các máy khách, vì một lần đăng nhập thành công và một tên tệp hiện ra đều dừng lại trước đích.

Phản hồi sơ bộ và phản hồi cuối cùng

Với STOR, phản hồi 125 hoặc 150 là sơ bộ. Nó cho biết máy chủ sẵn sàng thử và một kết nối dữ liệu đang mở, không phải đối tượng đã tồn tại ở dạng cuối cùng. Thao tác chỉ hoàn tất khi quá trình truyền đạt tới phản hồi hoàn thành tích cực, thường là 226 hoặc 250, trong ngữ cảnh của thao tác đó.

426 nghĩa là quá trình truyền đã bị hủy, và con số do một lệnh khác in ra không phải kết quả của lần tải lên này. Hãy đọc phản hồi thuộc về STOR đó, không phải con số cuối cùng trên màn hình. Nếu máy khách thoát trước khi phản hồi đó đến, bạn không có bằng chứng hoàn tất nào cả.

Kết nối điều khiển và kết nối dữ liệu

Xác thực và liệt kê thư mục dùng kết nối điều khiển. Các byte dùng một kết nối dữ liệu riêng, và điểm cuối của nó được thương lượng cho từng lần truyền. Đăng nhập thành công chứng minh đường điều khiển và không nói gì về việc địa chỉ dữ liệu có thể tiếp cận từ máy khách hay không.

Khi máy chủ không mở được kết nối dữ liệu, hãy điều tra điểm cuối đã thương lượng và đường dẫn được phép. Chế độ thụ động vẫn cần một địa chỉ dữ liệu và cổng dùng được, và tường lửa hay thiết bị NAT giữa máy khách với máy chủ có thể cho phiên điều khiển đi qua trong khi chặn dải dữ liệu. Khi máy chủ từ chối yêu cầu lưu trữ, hãy xem tên đường dẫn từ xa, quyền hoặc giới hạn lưu trữ. Không nhánh nào được giải thích bởi việc kết nối điều khiển đã xác thực.

FTP qua TLS và SFTP

FTP qua TLS vẫn là FTP: hai kết nối, các phản hồi FTP và một lần nâng cấp TLS trên mỗi kết nối. SFTP là một hệ thống con của SSH với một kết nối duy nhất và bộ lệnh hoàn toàn khác. Chúng chỉ chia sẻ mục đích và gần như không gì khác, nên một chẩn đoán đi xuyên giữa hai bên thường bắt đầu bằng việc so sánh nhầm nhật ký.

Đừng tắt TLS để một trợ giúp trung gian có thể kiểm tra phiên, và đừng coi lỗi SFTP là vấn đề phản hồi FTP. hướng dẫn curl ghi lại TLS tường minh, chế độ thụ động và các tùy chọn tải lên nếu bạn cần một bài kiểm thử bằng script, và đó là tài liệu tham chiếu cho việc mỗi cờ thực sự thay đổi điều gì.

Hãy chọn giao thức mà dịch vụ thực sự cung cấp trước khi gỡ lỗi nó. Một máy chủ chỉ nói SFTP sẽ không bao giờ tạo ra phản hồi 226, dù máy khách được cấu hình thế nào.

Tên tệp hiển thị và đối tượng đã lưu

Một tên tệp hiển thị có thể đại diện cho đối tượng chưa hoàn chỉnh, đặc biệt sau một lần truyền bị hủy hoặc một máy khách thoát sớm. Hãy đề nghị chủ dịch vụ so sánh kích thước của tệp kiểm thử dự định và mã băm nội dung đáng tin cậy với đối tượng đã lưu khi cần bảo toàn byte.

Chế độ nhị phân và ASCII là một so sánh khác làm thay đổi kết quả. Chế độ ASCII có thể chuyển đổi kết thúc dòng, nên các byte đã lưu khác với tệp cục bộ dù quá trình truyền thành công. Giữ chế độ nhị phân để kiểm tra từng byte, và đừng thêm tùy chọn chuyển đổi để làm một lần truyền thất bại trông khác đi.

Một STOR thông thường có thể thay thế tệp đang tồn tại, và quyền đăng nhập hoặc liệt kê thư mục không thiết lập quyền tạo hay thay thế đối tượng trong đó. Hãy dùng một tên từ xa chưa từng dùng cho bài kiểm thử.

Cần so sánh gì trước khi thử lại

Đừng nối thêm, tiếp tục hay lặp lại việc tải lên một cách mù quáng trên một tệp dở dang không chắc chắn. Hãy thống nhất với chủ dịch vụ xem nên bắt đầu lại dưới một tên mới, dùng quy trình khôi phục mà dịch vụ hỗ trợ, hay xóa đối tượng kiểm thử đã thất bại.

Hãy ghi kết quả thành một trong bốn phát biểu: việc đọc cục bộ thất bại, việc lưu trữ bị từ chối, quá trình truyền dữ liệu bị hủy, hoặc quá trình truyền hoàn tất và các byte đã lưu khớp. Bản ghi đó là kết quả mạnh hơn việc thay đổi shell, VPN và cài đặt FTP cùng lúc cho tới khi một tên tệp xuất hiện, và nó cho người tiếp theo biết nên kiểm tra giai đoạn nào. Hãy giữ văn bản phản hồi đã làm sạch cùng với phát biểu đó. Khi ấy, thử lại là một quyết định, không phải phản xạ.