Một file đã tải được gần hết thì mạng ngắt. Người dùng bấm tiếp tục và ứng dụng nối dữ liệu mới vào phần cũ. Cách làm này chỉ đúng nếu phần nhận tiếp thực sự thuộc cùng bản nội dung và bắt đầu ở đúng vị trí. Trong lúc chờ, máy chủ có thể đã thay file dù đường dẫn và tên tải vẫn giữ nguyên.
HTTP Range giúp yêu cầu một phần dữ liệu, còn If-Range đặt điều kiện cho việc dùng phần đó. Bài này dùng một file ASCII tổng hợp 12 byte để giải thích đường nhận trên client. Đây không phải báo cáo kiểm thử download của Onter, không hướng dẫn sửa máy chủ production và không đồng nhất tải xuống với cơ chế upload nhiều phần.
Một phần file cần đi cùng phiên bản và vị trí
Giả sử bản V1 có nội dung ABCDEFGHIJKL. Client đã giữ ABCD, tức bốn byte đầu với vị trí 0 đến 3 trong ví dụ ASCII này. Phần còn thiếu bắt đầu từ vị trí 4. Chỉ lưu con số “đã tải4 byte” chưa đủ cho lần tiếp: còn cần biết bốn byte ấy thuộc bản representation nào và có còn phù hợp với nội dung hiện tại hay không.
Trong bài thử giả định, có thể đặt nhãn validator là v1-demo để phân biệt bản. Đây chỉ là nhãn minh họa, không phải checksum đã đo hoặc thuật toán tạo ETag của một dịch vụ. Khi triển khai, client cần lưu validator thực mà cơ chế phía cung cấp hỗ trợ, cùng thông tin cần thiết để tiếp tục đúng phạm vi.
Tên file không thể thay vai trò đó. Một người có thể sửa nội dung bảng giá rồi tiếp tục dùng cùng tên “Bảng giá.pdf”. Cũng có thể hai URL khác nhau phục vụ cùng dữ liệu. Quyết định tiếp tục phải dựa trên hợp đồng tài nguyên và validator phù hợp, không chỉ dựa vào chuỗi tên hoặc phần trăm còn lại trên thanh tiến độ.
Với thiết kế lưu cục bộ, nên phân biệt bản tải dở với tài liệu đã bàn giao cho người nhận. Một tệp tạm có thể đang thiếu dữ liệu hoặc chờ đối chiếu. Không dùng cùng một thông báo hoàn tất cho việc đã nhận thêm byte và việc file cuối đã được xác nhận đủ điều kiện sử dụng trong quy trình.
HTTP Range là yêu cầu, không phải lời hứa luôn có phản hồi 206
RFC9110, mục14.2 định nghĩa Range trên GET để yêu cầu một hoặc nhiều vùng của representation. Máy chủ có thể bỏ qua Range. Do đó, client không được mặc định mọi phản hồi cho request có Range đều là một đoạn có thể nối vào bản cũ.
Với file tổng hợp ở trên, phần yêu cầu có thể mô tả bytes=4-. Trước khi quyết định lưu ở đâu, client đọc trạng thái và metadata của phản hồi thật. Một đường nhận được thiết kế chỉ có nhánh “mở file rồi append” sẽ khó xử lý trường hợp máy chủ trả về toàn bộ representation thay vì vùng yêu cầu.
Tài liệu206 Partial Content của MDN mô tả phản hồi cho một vùng có Content-Range, còn yêu cầu nhiều vùng có cấu trúc multipart riêng. Bài này giữ phạm vi một vùng để tránh đánh đồng body của một phản hồi nhiều phần với một chuỗi byte liên tục có thể ghi thẳng theo một offset.
Nhóm tích hợp cần chốt có thực sự hỗ trợ nhiều vùng hay không. Nếu không, ghi rõ giới hạn và chỉ tạo request theo hợp đồng đã hỗ trợ. Đừng bổ sung nhiều phần song song chỉ vì nghe có vẻ nhanh hơn; việc nhận, ghép và đối chiếu sẽ có thêm các quyết định mà một ví dụ tải tiếp đơn giản chưa kiểm chứng.
If-Range tránh nối phần mới vào một bản đã thay đổi
Theo mục13.1.5 của RFC9110, If-Range diễn đạt điều kiện: nếu representation chưa đổi theo validator thì xét Range; nếu điều kiện không khớp thì bỏ qua Range và chuyển toàn bộ representation mới. Client không được dùng weak ETag cho header này. Việc có điều kiện không tự bắt mọi máy chủ phải hỗ trợ yêu cầu vùng.
MDN về If-Range trình bày khác biệt giữa nhánh206 cho phần nội dung và nhánh200 cho toàn bộ nội dung khi điều kiện không đạt. Trong ứng dụng, hai nhánh cần cách lưu phù hợp;200 không phải một lỗi cần sửa thành206 để thanh tiến độ tiếp tục chạy.
Trở lại ví dụ: V1 là ABCDEFGHIJKL, đã có ABCD. Nếu representation vẫn phù hợp và máy chủ đáp ứng vùng4–11, phần còn lại là EFGHIJKL. Nhưng giả sử bản hiện tại đã thành abcdEFGHIJKL, client không nên giữ bốn byte viết hoa cũ rồi ghép thêm dữ liệu của bản mới. Kết quả đó không phải nội dung của bản hiện hành.
Hai bản trong ví dụ có cùng độ dài và cùng tên giả định. Điều này cho thấy chỉ kiểm tổng byte hoặc tên chưa phát hiện được mọi nhầm phiên bản. Những con số trong bài là dữ liệu biên tập để giải thích quyết định; chưa có request hay phép kiểm nào được thực thi trên một server thật.
Quyết định ghi file sau khi đọc đúng phản hồi
| Quan sát | Điểm cần đối chiếu | Quyết định không nên tự động hóa mù |
|---|---|---|
| 206 cho vùng mong muốn | Vị trí, validator và dữ liệu nhận theo hợp đồng | Cứ thấy206 là append ở cuối file |
| 200 với toàn bộ representation | Đường lưu một bản đầy đủ mới | Nối toàn bộ bản mới vào phần cũ |
| Không đúng hợp đồng hoặc thiếu bằng chứng | Giữ trạng thái chưa hoàn tất và thông tin tối thiểu | Đổi tên thành hoàn tất để bàn giao |
Bảng là thiết kế câu hỏi cho consumer, không thay tài liệu API của dịch vụ đang dùng. Với nhánh206, cần biết vùng nhận về có thực sự bắt đầu ở vị trí dự kiến và body được xử lý theo dạng nào. Không lấy vị trí đang có của con trỏ ghi làm bằng chứng thay cho đọc metadata phản hồi.
Với nhánh200, cần một đường nhận toàn bộ bản mới. Cách giữ tệp tạm và chuyển nó thành bản bàn giao cuối phải được thiết kế để tránh để lộ một file đang viết dở như tài liệu đã hoàn tất. Bài không khẳng định một thao tác đổi tên là nguyên tử trên mọi môi trường; đội triển khai cần kiểm cơ chế lưu trữ cụ thể.
Nếu phản hồi không đáp ứng hợp đồng, đừng cố cứu bằng cách cắt hoặc chèn byte để kích thước nhìn khớp. Giữ phần cần thiết để người phụ trách điều tra và xác định có thể thử lại đường nào. Một mã trạng thái khác hoặc một trang lỗi không nên bị ghi vào vị trí của dữ liệu tài liệu chỉ vì vẫn nhận được body.
Trường hợp client gặp lỗi đọc phản hồi trước khi biết trạng thái đầy đủ cần được giữ là chưa rõ kết quả nhận. Không nhất thiết xóa ngay mọi phần đã có; cũng không mặc định có thể dùng tiếp. Thiết kế cần một biên bản đủ để lần sau quyết định theo phiên bản và phạm vi, thay vì dựa vào cảm giác rằng file đã tải gần hết.
Nghiệm thu bằng việc thay bản ở giữa hai lần nhận
Một ca thuận chưa đủ kiểm khả năng tải tiếp. Trên môi trường được phép, chuẩn bị hai tài nguyên tổng hợp với cùng tên nhưng khác nội dung và validator phù hợp. Ghi kết quả mong đợi trước khi chạy: cùng bản có thể tiếp tục theo cơ chế hỗ trợ; khác bản không được ghép thành một tài liệu lai. Sau thực hiện mới điền kết quả thật vào receipt.
Cần một ca máy chủ không đáp ứng Range và trả representation đầy đủ. Client phải đi qua nhánh lưu phù hợp thay vì lặp request mãi hoặc tăng kích thước file vì append. Ca này giúp kiểm lời hứa của consumer, không nhằm ép máy chủ thay cấu hình chỉ để phù hợp với một bộ thử tự tạo.
Thêm một lần ngắt trong khi nhận phần còn lại và xác minh sổ tải dở vẫn phản ánh dữ liệu đã giữ. Không suy từ số byte đã báo trên giao diện rằng file cục bộ đã được ghi đủ. Khi mô tả kết quả, ghi rõ điểm quan sát là body nhận, dữ liệu lưu hay file đã bàn giao; chúng không phải lúc nào cũng cùng một thời điểm.
Đường tải có quyền hoặc thời hạn cần được thử theo hợp đồng riêng. Bài link tải file có thời hạn giải thích vì sao quyền bắt đầu tải không tự bảo đảm mọi lần tiếp tục sau đó còn được chấp nhận. Không đổi file thành công khai để làm một ca resume thành công.
Đừng nhầm kiểm này với nghiệm thu upload nhiều phần. Bài đó theo việc gửi các phần lên và hoàn tất đối tượng ở nhà cung cấp. Ở đây, consumer đang nhận representation từ HTTP và quyết định ghi phần nào vào bản cục bộ. Hai đường có thể cần bằng chứng khác nhau dù cùng quan tâm đúng phiên bản và tính toàn vẹn.
Receipt bàn giao nên giữ định danh tài nguyên đã được phép, trạng thái từng chặng, validator theo quy tắc lưu tối thiểu và kết quả đối chiếu file cuối. Không đưa URL ký còn hiệu lực, header xác thực hoặc nội dung khách hàng vào báo cáo rộng quyền. Bộ dữ liệu tổng hợp đã đủ cho các tình huống cơ bản trong bài.
Nếu cần thiết kế client nhận tài liệu lớn hoặc bổ sung tải tiếp cho một tích hợp, hãy mang tài liệu endpoint và các nhánh mong muốn khi Nhận tư vấn & báo giá. Giá: Liên hệ. Phạm vi cần chốt là nhận đúng bản và giữ đúng trạng thái bàn giao, trước khi tối ưu số kết nối hay thời gian tải.
