Người dùng gửi một request hợp lệ về nghiệp vụ nhưng nhận lỗi 413 trước khi ứng dụng đọc được nội dung. Nâng giới hạn proxy có thể làm lỗi biến mất, đồng thời chuyển lượng dữ liệu quá lớn xuống một parser dễ cạn RAM. Kích thước request API cần một hợp đồng xuyên các lớp, không phải một cấu hình riêng lẻ.
413 cho biết điều gì và chưa cho biết điều gì?
Thông thường mã này liên quan nội dung request vượt giới hạn mà một lớp chấp nhận. Cần xác định phản hồi đến từ CDN, reverse proxy, framework hay service đích. Nếu ứng dụng không có log tương ứng, đừng kết luận lỗi nằm trong nghiệp vụ. Request có thể chưa tới controller, hoặc log có thể bị lấy mẫu; cần thêm bằng chứng ở lớp phía trước.
NGINX có chỉ thị client_max_body_size cho giới hạn body và trả 413 khi vượt. Đây là ví dụ về một cổng kiểm, không phải tổng giới hạn của mọi hệ thống. Lớp ứng dụng vẫn có thể đặt trần thấp hơn, và dịch vụ bên ngoài có hợp đồng khác.
Byte truyền, dữ liệu giải mã và bộ nhớ không bằng nhau
Một file nhị phân được nhúng dưới dạng text có thể lớn hơn bản gốc. Dữ liệu nén có thể nhỏ trên đường truyền nhưng phình ra khi giải nén. Parser còn có thể tạo cấu trúc trong bộ nhớ lớn hơn chuỗi nhận vào. Vì vậy, giới hạn truyền không thay giới hạn giải nén, độ sâu cấu trúc hoặc số phần tử được xử lý.
Đừng cộng các con số này như những khoản độc lập nếu chúng đang mô tả cùng vùng dữ liệu. Mục đích là biết mỗi trần được đo ở đâu, đơn vị gì và chủ sở hữu nào chịu trách nhiệm. Nếu thư viện đọc toàn body trước khi kiểm, trần ở controller có thể đã quá muộn để bảo vệ bộ nhớ của quá trình đọc.
Lập hợp đồng theo endpoint và loại đầu vào
| Lớp | Cần ghi | Ai xác nhận |
|---|---|---|
| Cổng nhận | Byte body, kiểu nội dung, thời gian đọc | Owner edge/proxy |
| Parser | Số trường, độ sâu, byte giải mã | Owner framework |
| Nghiệp vụ | Số dòng hoặc phần tử cho một công việc | Owner sản phẩm |
| Tích hợp | Trần của API đích và cách chia công việc | Owner tích hợp |
Không cần mọi endpoint cùng trần. Một form tư vấn ngắn khác upload tài liệu đã được cấp quyền. Endpoint không có nhu cầu nhận file nên không mở kiểu nội dung và dung lượng tương đương luồng upload. Chính sách nên được giải thích trước thao tác, để người dùng biết file nào có thể gửi thay vì đợi tải xong mới thấy lỗi chung.
Giới hạn theo số phần tử còn phải xét chi phí từng phần tử. Mười dòng có trường text rất dài khác mười dòng ngắn; một cấu trúc lồng nhau sâu có thể gây chi phí khác danh sách phẳng. Quy tắc kiểm dữ liệu cần phù hợp loại công việc, không dùng duy nhất Content-Length do client báo làm bằng chứng kích thước thật.
Ví dụ giả định: file được nhận ở proxy nhưng không ở API đích
Một luồng nhận tài liệu cho phép file trong trần đã thống nhất, nhưng API OCR đích chỉ nhận tài liệu nhỏ hơn. Nếu ứng dụng nhận rồi gửi nguyên file, lỗi xuất hiện muộn và người dùng không biết dữ liệu đang ở đâu. Một phương án là xác định tính khả thi trước, ghi trạng thái chờ và hướng xử lý được duyệt; không tự chia file có thể làm mất ngữ cảnh chứng từ.
Nếu dùng upload ngoài request nghiệp vụ, quyền tải, thời hạn và ràng buộc file vẫn cần được kiểm. Chuyển file sang object storage không tự giải quyết kiểm loại nội dung, quyền truy cập hoặc tổng chi phí xử lý. Hợp đồng cần nói rõ lúc nào chỉ là nhận file và lúc nào công việc được chấp nhận.
Thử ở ngay dưới, đúng và ngay trên trần
Trong môi trường thử, chuẩn bị đầu vào gần ranh giới theo đúng đơn vị mà từng lớp dùng. Kiểm request không khai báo độ dài nếu giao thức hỗ trợ, kiểu nội dung sai, payload nhiều trường và dữ liệu nén nếu hệ thống cho phép. Đừng bật xử lý nén chỉ để có thêm một ca test.
Kết quả cần kiểm cả mã lỗi, thông báo, dữ liệu tạm có được dọn theo chính sách và công việc có bị khởi chạy một phần không. Không log toàn payload quá lớn để điều tra lỗi dung lượng. Giữ kích thước đo, loại đầu vào, mã request và lớp từ chối là đủ cho bước đầu trong nhiều tình huống.
Chọn một cơ chế lớn hơn chỉ khi có lý do
Luồng nhiều phần phù hợp một số file lớn, nhưng phải có hợp đồng kiểm toàn vẹn multipart. Nếu dữ liệu là nhiều tác vụ độc lập, API xử lý lô với kết quả từng phần giải quyết trạng thái khác giới hạn byte. Để trao đổi phạm vi API với Onter, chọn một endpoint và loại đầu vào cụ thể; chưa cần nới toàn bộ hệ thống hay gửi file riêng của khách hàng.
