HTTP 507 Insufficient Storage: xác định hop khi xuất tệp

HTTP 507 Insufficient Storage là mã WebDAV báo máy chủ không đủ chỗ để lưu thứ mà request muốn ghi. Với pipeline xuất tệp crawl lên kho WebDAV hay kho lưu trữ, mã này hay bị đọc nhầm thành lỗi proxy hoặc lỗi băng thông, rồi người vận hành đổi IP trong khi kho vẫn đầy. ProxyVN dựng một máy chủ WebDAV tối giản có quota 64KB và một proxy chuyển tiếp ghi Via. Lab chạy requests và httpx thật để xác định hop nào phát 507, đọc thân lỗi XML, đo quota và thử lại sau khi giải phóng dung lượng.

HTTP 507 Insufficient Storage: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và ranh giới.

Bài toán cần giải

Một job đêm đẩy các phần CSV lên kho WebDAV của đối tác qua proxy công ty. Ba phần đầu lên được, phần thứ tư báo 507. Retry chung của job thử thêm ba lần, rồi báo lỗi. Sáng hôm sau, người trực thấy chữ "Insufficient Storage", nghĩ proxy hết dung lượng, mở ticket với bộ phận mạng. Trong khi đó kho WebDAV vẫn đầy và đêm sau lại hỏng đúng chỗ cũ.

Đầu ra nghiệm thu

Đầu ra là một bảng hop response cho từng thao tác: mã, Server, Via, precondition trong thân lỗi, và kết luận hop nào phát mã. Kèm theo là số đo quota trước và sau mỗi lần ghi, và phép thử ghi lại sau khi xóa bớt tệp. Bảng phải cho thấy 507 đến từ origin, còn 502 khi origin chết đến từ proxy.

Ranh giới với bài 503 và 413

Bài lỗi 503 Service Unavailable nói về origin quá tải hoặc bảo trì, thường thử lại sau được. Bài lỗi 413 Content Too Large nói về request quá lớn so với giới hạn của server. Mã 507 khác cả hai: request có thể nhỏ, server vẫn sống, chỉ là chỗ lưu không còn. Thử lại không có ích cho tới khi có người giải phóng dung lượng.

Không phải lỗi băng thông proxy

Gói proxy tính theo băng thông có thể hết lưu lượng, nhưng proxy khi đó trả mã khác, thường là lỗi xác thực hoặc từ chối kết nối, tùy nhà cung cấp. 507 là mã của máy chủ lưu trữ nói về dung lượng của nó. Bài này dựa vào header Server và Via để tách hai trường hợp, không dựa vào cảm giác.

Giới hạn của lab

Máy chủ WebDAV trong lab là một http.server tự viết, chỉ hỗ trợ PUT, MKCOL, DELETE, PROPFIND tối giản, không có khóa, không có thuộc tính tùy ý. Quota 64KB do ProxyVN đặt, tính bằng tổng kích thước tệp. Quy tắc từ chối MKCOL chỉ khi quota đã chạm trần cũng do lab đặt. Thứ thật trong lab là hai thư viện client, cơ chế retry của urllib3 và các header đi qua proxy.

Ai nên đọc

Người vận hành pipeline xuất tệp lên WebDAV, Nextcloud, SharePoint hay kho lưu trữ có quota. Người viết retry chung cho mọi lỗi 5xx. Người phải trả lời câu hỏi lỗi nằm ở proxy hay ở kho khi có sự cố đêm.

Xác định HTTP 507 Insufficient Storage từ WebDAV và storage khi pipeline xuất tệp

Phần này tóm tắt các chuẩn liên quan, chỉ giữ ý ảnh hưởng tới client.

WebDAV vẫn còn trong pipeline

WebDAV có tuổi đời lâu, nhưng vẫn là giao thức chung của nhiều kho tệp doanh nghiệp, dịch vụ đồng bộ và công cụ như rclone. Pipeline crawl dùng nó để đẩy kết quả cho bên nhận không có API riêng. Bài rclone proxy có nhắc cách rclone đi qua proxy khi làm việc với các kho như vậy.

Định nghĩa trong RFC 4918

Theo RFC 4918 mục 11.5, mã 507 nghĩa là method không thực hiện được trên tài nguyên vì server không thể lưu đại diện cần thiết để hoàn tất request. Trạng thái này được coi là tạm thời. Nếu request là kết quả của hành động người dùng, request không được lặp lại cho tới khi người dùng chủ động yêu cầu lần nữa.

Câu "không được lặp lại"

Câu cuối là điểm quan trọng nhất với pipeline. RFC không cấm thử lại sau khi tình hình thay đổi, nhưng nói rõ không tự lặp lại. Một retry chung chung bắn lại PUT ba lần ngay sau 507 đi ngược tinh thần này. Phần lab sẽ cho thấy hậu quả cụ thể.

507 xuất hiện ở đâu trong WebDAV

RFC 4918 nhắc tới 507 cho nhiều method. PROPPATCH dùng 507 khi server không đủ chỗ ghi thuộc tính. MKCOL dùng 507 khi tài nguyên không đủ chỗ ghi trạng thái sau khi thực hiện. COPY và MOVE dùng 507 khi đích không đủ chỗ. PUT là trường hợp phổ biến nhất trong pipeline xuất tệp.

Không chỉ WebDAV dùng 507

Mã 507 được định nghĩa trong RFC WebDAV, nhưng một số API lưu trữ không theo WebDAV cũng mượn mã này khi tài khoản hết hạn mức. Khi đó thường không có thân lỗi XML theo namespace DAV. Client vẫn áp được quy tắc chính của bài: xác định hop, không tự thử lại, giải phóng rồi mới gửi.

Quota trong RFC 4331

Hai precondition của 507

RFC 4331 định nghĩa hai thuộc tính DAV:quota-available-bytes và DAV:quota-used-bytes. Thuộc tính đầu là số byte còn có thể cấp thêm trước khi bị từ chối, bắt buộc với collection. Thuộc tính sau là số byte đang dùng. Client đọc hai thuộc tính bằng PROPFIND trước khi ghi.

Hai precondition khi báo lỗi

RFC 4331 nói 507 nên được dùng khi request vượt quota hoặc giới hạn lưu trữ vật lý. Để phân biệt với các vấn đề lưu trữ khác, server nên gửi thân lỗi XML chứa precondition: DAV:quota-not-exceeded khi vượt quota, DAV:sufficient-disk-space khi ổ vật lý hết chỗ. Đây là thông tin quý nhất trong phản hồi.

Hai precondition, hai người sửa

Vượt quota là chuyện cấu hình tài khoản: xóa bớt tệp hoặc xin nâng hạn mức. Hết ổ vật lý là chuyện hạ tầng của bên vận hành kho. Đọc đúng precondition giúp gửi ticket đúng người ngay từ đầu, thay vì chuyền qua lại nhiều bộ phận.

Bảng: Hai precondition, hai người sửa

Precondition	Ý nghĩa	Ai xử lý
quota-not-exceeded	Tài khoản hoặc thư mục vượt hạn mức	Người dùng kho, quản trị tài khoản
sufficient-disk-space	Ổ vật lý của server hết chỗ	Bên vận hành máy chủ lưu trữ
không có thân lỗi	Không rõ nguyên nhân cụ thể	Đọc log phía server, hỏi bên kho

Quota có thể không chính xác

RFC 4331 ghi rõ client nên dự liệu rằng khi quota-available-bytes gần 0 thì các lần cấp phát tiếp theo có thể bị từ chối, và không gian còn lại có thể bị tài nguyên khác dùng mất. Vậy nên đọc quota trước khi ghi chỉ là ước lượng. Client vẫn phải xử lý 507 kể cả khi quota báo còn chỗ.

Chọn WebDAV và storage fixture có giới hạn dung lượng cho HTTP 507 Insufficient Storage

Phần này dựng lab, chạy thật trên Python 3.12.10.

Máy chủ WebDAV tối giản

Máy chủ nghe ở 127.0.0.1:9751, header Server là dav-lab/0.1. Tệp lưu trong từ điển, quota 65.536 byte. PUT kiểm tổng dung lượng sau khi ghi, vượt quota thì trả 507 kèm thân lỗi XML có quota-not-exceeded.

def do_PUT(self):
    b = self.rbody()
    old = len(FILES.get(self.path, b""))
    if used() - old + len(b) > QUOTA:
        err = (b'<?xml version="1.0" encoding="utf-8"?>\n'
               b'<D:error xmlns:D="DAV:"><D:quota-not-exceeded/></D:error>')
        return self.out(507, err, 'application/xml; charset="utf-8"')
    created = self.path not in FILES
    FILES[self.path] = b
    self.out(201 if created else 204)

Phép tính trừ old cho phép ghi đè tệp cũ mà không bị tính hai lần.

PROPFIND trả quota

PROPFIND Depth 0 trên /exports/ trả multistatus 207 có hai thuộc tính quota. Client đọc bằng lxml theo namespace DAV.

def quota(s):
    r = s.request("PROPFIND", B + "/exports/", headers={"Depth": "0"}, proxies=P)
    t = etree.fromstring(r.content); ns = {"D": "DAV:"}
    return (int(t.findtext(".//D:quota-available-bytes", namespaces=ns)),
            int(t.findtext(".//D:quota-used-bytes", namespaces=ns)))

Lần đọc đầu trả (65536, 0): còn đủ 64KB, chưa dùng byte nào.

Proxy chuyển tiếp có Via

Proxy nghe ở 127.0.0.1:9752, chuyển tiếp PUT, MKCOL, DELETE, PROPFIND tới origin, giữ nguyên header Server của origin, thêm Via: 1.1 proxy-lab. Khi không nối được origin, proxy tự sinh 502 với Server: proxy-lab/0.1. Đây là cách nhiều proxy thật hoạt động, dù tên và định dạng khác nhau.

Lần đầu lab đọc sai hop

Bản đầu của proxy lab dùng hàm gửi phản hồi mặc định của http.server, hàm này tự thêm Server của proxy. Kết quả là header Server bị ghép hai giá trị, và hàm xác định hop đọc sai, kết luận mọi phản hồi đến từ proxy. Lab sửa bằng cách chỉ gửi dòng trạng thái rồi tự đặt Server. Bài học: trước khi tin header để định vị lỗi, kiểm proxy của mình viết gì vào header.

Hàm xác định hop

Hàm hop đọc Server, Via và thân lỗi. Server bắt đầu bằng dav-lab thì mã do origin phát. Server bắt đầu bằng proxy-lab thì mã do proxy phát. Thân lỗi XML được đọc để lấy tên precondition.

def hop(r):
    via = r.headers.get("Via"); srv = r.headers.get("Server")
    prec = None
    if "xml" in r.headers.get("Content-Type", "") and r.status_code == 507:
        prec = [etree.QName(e).localname for e in etree.fromstring(r.content)]
    origin = srv is not None and srv.startswith("dav-lab")
    who = "origin dav-lab" if origin else "proxy-lab" if (srv or "").startswith("proxy-lab") else "?"
    return f"{r.status_code} {r.reason} | Server={srv} Via={via} | precondition={prec} | phat_sinh_tai={who}"

Tên dav-lab và proxy-lab là của lab. Với hệ thật, thay bằng chuỗi Server của kho và của proxy mà anh em đang dùng.

Vì sao tự viết máy chủ

Máy chủ WebDAV thật cần cài đặt và cấu hình quota, việc này ngoài phạm vi máy lab. Máy chủ tự viết cho phép đặt quota chính xác tới byte và biết trước lần ghi nào sẽ hỏng. Đổi lại, hành vi của nó chỉ là một cách hiểu RFC, không đại diện cho mọi kho thật.

Cấu trúc đường dẫn

Mọi tệp nằm dưới /exports/, quota tính chung cho cả kho. Kho thật có thể tính quota theo người dùng, theo thư mục hoặc theo cả hai. Khi đọc quota, gửi PROPFIND đúng tới thư mục đích của pipeline, vì giá trị ở thư mục gốc có thể khác.

Kích thước phần tệp

Mỗi phần CSV giả lập có 20KB. Ba phần dùng 60KB, phần thứ tư cần thêm 20KB khi chỉ còn 4KB. Con số được chọn để 507 xuất hiện đúng ở lần ghi thứ tư, dễ đọc trong output.

Gửi thao tác ghi và xác định hop phát HTTP 507 Insufficient Storage

Phần này chạy ghi thật qua proxy với requests 2.34.2.

Bốn lần PUT

Bốn lần PUT qua proxy

Output thật dưới đây cho thấy ba lần đầu nhận 201, lần thứ tư nhận 507. Mọi phản hồi đều có Server của origin và Via của proxy.

PUT part-1.csv 20KB -> 201 Created | Server=dav-lab/0.1 Python/3.12.10 Via=1.1 proxy-lab | phat_sinh_tai=origin dav-lab | quota: (45056, 20480)
PUT part-2.csv 20KB -> 201 Created | Server=dav-lab/0.1 ... | quota: (24576, 40960)
PUT part-3.csv 20KB -> 201 Created | Server=dav-lab/0.1 ... | quota: (4096, 61440)
PUT part-4.csv 20KB -> 507 Insufficient Storage | Server=dav-lab/0.1 ... Via=1.1 proxy-lab | precondition=['quota-not-exceeded'] | phat_sinh_tai=origin dav-lab | quota: (4096, 61440)

Sau lần 507, quota vẫn là 4096 còn lại, 61440 đã dùng. Không có byte nào của part-4 được ghi.

Đọc kết luận

Ba dấu hiệu cùng chỉ một hướng. Server là dav-lab, nên origin phát mã. Via có proxy-lab, nên request có đi qua proxy và proxy chỉ chuyển tiếp. Thân lỗi có quota-not-exceeded, nên lý do là vượt hạn mức. Không có dấu hiệu nào cho thấy proxy liên quan tới việc hết chỗ.

MKCOL vẫn được nhận

Lab gửi MKCOL tạo thư mục ngày, nhận 201. Quy tắc của lab chỉ từ chối MKCOL khi quota chạm trần hẳn. Server thật có thể từ chối MKCOL ngay khi gần đầy, vì thư mục cũng tốn chỗ cho metadata. Đừng dùng MKCOL thành công làm bằng chứng kho còn chỗ.

Cùng một dòng log có Via của proxy không có nghĩa là proxy gây lỗi. Via chỉ nói request đã đi qua đó.

Thời gian phản hồi cũng là manh mối

Trong lab, 507 trả về gần như tức thì vì máy chủ kiểm quota trước khi đọc xong. Kho thật có thể nhận hết body rồi mới báo, nên thời gian phản hồi dài gần bằng thời gian tải lên. Nếu 507 đến sau khi đã gửi hết tệp lớn, đó là thêm một lý do để kiểm quota trước khi gửi.

So với 502 do proxy sinh

Lab tắt origin, gửi lại PUT. Proxy không nối được, tự sinh 502 Bad Gateway với Server proxy-lab/0.1. Hàm hop kết luận phát sinh tại proxy-lab.

PUT khi origin chet -> 502 Bad Gateway | Server=proxy-lab/0.1 Via=1.1 proxy-lab | precondition=None | phat_sinh_tai=proxy-lab

Đặt hai dòng 507 và 502 cạnh nhau, khác biệt hiện ra ngay: cùng có Via, nhưng Server khác, và chỉ 507 có thân lỗi WebDAV.

Body lỗi không phải lúc nào cũng có

RFC 4331 dùng từ nên khi nói về thân lỗi có precondition. Một số kho trả 507 với thân rỗng hoặc trang HTML chung. Client phải xử lý cả hai trường hợp: có precondition thì log tên, không có thì log nguyên văn vài trăm byte đầu của thân để người sau đọc.

httpx cho cùng kết quả

httpx 0.28.1 qua proxy gửi PUT 40KB khi còn 24KB. Kết quả 507 Insufficient Storage, Via 1.1 proxy-lab, Server dav-lab/0.1. Hành vi đọc mã và header của hai thư viện giống nhau. Cả hai không tự thử lại khi chưa cấu hình retry.

Proxy thật có thể ghi khác

Proxy trong lab ghi Via với tên proxy-lab. Squid, Nginx, HAProxy và các proxy thương mại có cách ghi riêng, một số không ghi Via theo mặc định. Trước khi dùng bảng hop ở môi trường thật, gửi một request bình thường qua proxy và ghi lại các header nó thêm vào.

Bảng hop response

Bảng dưới gom các phản hồi chính của lab.

Bảng: Bảng hop response

Thao tác	Mã	Server	Via	Precondition	Hop phát mã
PUT part-1..3	201	dav-lab	proxy-lab	không	origin
PUT part-4	507	dav-lab	proxy-lab	quota-not-exceeded	origin
PUT khi origin chết	502	proxy-lab	proxy-lab	không	proxy
PUT 40KB qua httpx	507	dav-lab	proxy-lab	không đọc	origin
PUT part-4 sau khi xóa	201	dav-lab	proxy-lab	không	origin

Khi không có header Server

Nhiều kho thật ẩn header Server hoặc để giá trị chung. Khi đó dựa vào thân lỗi. Thân lỗi XML theo namespace DAV gần như chắc là của máy chủ WebDAV. Proxy thường trả trang HTML hoặc văn bản ngắn. Nếu cả hai đều mơ hồ, so thời gian phản hồi và log phía proxy để biết request có tới origin hay không.

Giải phóng hoặc tăng tài nguyên lab rồi thử lại HTTP 507 Insufficient Storage

Phần này cho thấy retry sai cách và retry đúng cách.

Retry chung cho mọi 5xx

Retry chung bắn lại 4 lần

Lab cấu hình Session với Retry của urllib3: total 3, backoff 0,1, status_forcelist gồm mọi mã từ 500 đến 599, cho phép mọi method. Đây là cấu hình hay thấy trong script copy từ nhiều nơi.

rs = requests.Session()
rs.mount("http://", HTTPAdapter(max_retries=Retry(
    total=3, backoff_factor=0.1, status_forcelist=list(range(500, 600)),
    allowed_methods=None, raise_on_status=False)))
r = rs.put(f"{B}/exports/part-4.csv", data=blob, proxies=P)

allowed_methods=None nghĩa là thử lại cả PUT, vốn không được thử lại mặc định trong urllib3.

Kết quả của retry chung

Sau 0,67 giây, kết quả vẫn là 507. Origin nhận 4 PUT cho cùng một tệp. Quota không đổi, vẫn (4096, 61440). Ba lần thử thêm không làm gì ngoài tốn băng thông, và với tệp lớn hàng trăm MB thì tốn rất nhiều.

ket qua 507 sau 0.67 s, server nhan 4 PUT, quota van: (4096, 61440)

Đây là minh họa trực tiếp cho câu trong RFC 4918 về việc không tự lặp lại request.

Retry của thư viện không biết ngữ nghĩa

urllib3 chỉ thấy một mã nằm trong danh sách và làm theo. Nó không biết 507 nghĩa là kho đầy, càng không biết thử lại sẽ vô ích. Trách nhiệm phân loại mã thuộc về người cấu hình. Đây là lý do nên đọc kỹ danh sách status_forcelist trước khi dán vào dự án.

Loại 507 khỏi danh sách retry

Sửa đơn giản nhất là bỏ 507 khỏi status_forcelist. Retry vẫn giữ cho 502, 503, 504 là các mã có thể tự khỏi. 507 đi vào nhánh riêng: dừng job xuất, báo người vận hành kèm precondition và quota hiện tại.

TRANSIENT = [502, 503, 504]
retry = Retry(total=3, backoff_factor=0.5, status_forcelist=TRANSIENT,
              allowed_methods=frozenset({"GET", "PUT", "PROPFIND"}))

Đoạn này là ví dụ triển khai, lab chưa chạy riêng cấu hình này.

Giải phóng dung lượng

Lab xóa part-1 và part-2 bằng DELETE, mỗi lệnh trả 204. Quota mới là (45056, 20480): còn 44KB, đang dùng 20KB của part-3. Trong pipeline thật, bước này có thể là xóa phần đã được bên nhận lấy về, dọn tệp tạm, hoặc xin nâng hạn mức.

Thử lại một lần

Sau khi quota đủ, lab gửi lại PUT part-4 đúng một lần. Kết quả 201 Created, Server dav-lab, Via proxy-lab. Quota sau đó (24576, 40960). Đây là lần thử lại hợp lệ theo RFC: tình hình đã đổi, và có quyết định chủ động gửi lại.

DELETE part-1.csv -> 204
DELETE part-2.csv -> 204
quota: (45056, 20480)
PUT part-4.csv -> 201 Created | Server=dav-lab/0.1 ... | phat_sinh_tai=origin dav-lab | quota: (24576, 40960)

Giải phóng có chọn lọc

Xóa phần đã được bên nhận xác nhận là an toàn nhất. Xóa phần chưa ai lấy là mất dữ liệu. Pipeline nên có sổ ghi phần nào đã được xác nhận nhận về, rồi chỉ dọn những phần đó. Nếu không có xác nhận, nâng hạn mức là lựa chọn đúng hơn xóa.

Kiểm quota trước khi ghi

Pipeline có thể đọc quota-available-bytes trước khi gửi một phần lớn. Nếu còn ít hơn kích thước phần, dừng sớm thay vì gửi rồi nhận 507. Cách này tiết kiệm băng thông nhất với tệp lớn. Nhớ RFC 4331 nói quota chỉ là ước lượng, nên vẫn phải xử lý 507.

Chia nhỏ phần tệp

Với kho gần đầy, phần nhỏ giúp tận dụng chỗ còn lại và giảm lượng dữ liệu phải gửi lại khi hỏng. Nhưng chia quá nhỏ làm số tệp tăng, mỗi tệp tốn thêm metadata. Kích thước phần nên chọn theo hạn mức của kho và tốc độ bên nhận lấy tệp về.

Ghi dở và tệp rác

Lab không có ca ghi dở: máy chủ lab từ chối trước khi lưu. Máy chủ thật có thể đã ghi một phần rồi mới phát hiện hết chỗ, để lại tệp dở. Sau 507, pipeline nên PROPFIND kiểm tệp đích có tồn tại không, có thì xóa trước khi thử lại, tránh bên nhận lấy về tệp hỏng.

Đối soát dung lượng và response để HTTP 507 Insufficient Storage không đổ lỗi tuyến proxy

Phần này biến kết quả lab thành quy trình xử lý sự cố.

Bốn câu hỏi khi gặp 507

Khi job báo 507, trả lời lần lượt bốn câu. Header Server nói hop nào phát mã. Thân lỗi có precondition nào. Quota hiện tại là bao nhiêu. Có tệp dở ở đích không. Bốn câu này đủ để viết ticket đúng người với đủ bằng chứng.

Mẫu ghi log

Mỗi lần ghi, log nên có: đường dẫn đích, kích thước, mã, Server, Via, precondition, quota trước và sau nếu đọc được. Log như vậy cho phép trả lời câu hỏi lỗi ở đâu mà không cần chạy lại.

{"op": "PUT", "path": "/exports/part-4.csv", "bytes": 20480, "status": 507,
 "server": "dav-lab/0.1", "via": "1.1 proxy-lab",
 "precondition": "quota-not-exceeded", "quota_before": [4096, 61440]}

Dòng log mẫu dựng từ output của lab.

Phân loại theo mã trong code

Hàm xử lý kết quả ghi nên có ba nhánh. Mã 2xx thì ghi sổ thành công. Mã 507 thì dừng lô, log precondition và quota, báo người vận hành. Mã 502, 503, 504 thì xem Server để biết hop, rồi mới để retry tự động xử lý. Mọi mã khác đi vào nhánh lỗi chung kèm thân lỗi.

Proxy chỉ cần kiểm khi Server là proxy

Theo bảng hop, proxy chỉ là nghi phạm khi phản hồi mang Server hoặc dấu hiệu của proxy, hoặc khi không có phản hồi nào. 507 có Server của kho và thân lỗi DAV thì proxy không có vai trò gì. Đổi IP, đổi proxy không giải phóng được byte nào trên kho.

Kiểm thẳng không qua proxy

Nếu còn nghi, gửi một PROPFIND thẳng tới kho từ máy có quyền, không qua proxy. Quota đọc được giống với khi qua proxy thì proxy không thay đổi gì. Bước này mất vài giây và chấm dứt tranh luận giữa đội dữ liệu và đội mạng.

Ticket gửi bên kho

Ticket tốt có đủ: thời điểm, đường dẫn đích, kích thước, mã 507, nguyên văn thân lỗi, quota đọc được trước và sau, và xác nhận đã kiểm thẳng không qua proxy. Bên kho đọc xong biết ngay việc cần làm, không phải hỏi lại.

Theo dõi quota như chỉ số

Đọc quota định kỳ, vẽ đường dung lượng còn lại. Khi đường dốc xuống nhanh, báo trước khi chạm 0. Đây là cách duy nhất để 507 không xảy ra vào lúc hai giờ sáng.

507 với tệp ghi đè

Lab tính dung lượng có trừ tệp cũ khi ghi đè. Máy chủ thật có thể giữ phiên bản cũ, khi đó ghi đè cũng tốn thêm chỗ. Nếu kho có tính năng lưu phiên bản, quota có thể đầy dù tổng kích thước tệp hiện hành còn nhỏ. Kiểm cấu hình phiên bản của kho khi số liệu không khớp.

Dọn kho theo lịch

Thay vì chờ 507, lên lịch dọn các phần cũ hơn một ngưỡng thời gian đã thỏa thuận với bên nhận. Lịch dọn chạy trước job xuất đêm, đọc quota sau khi dọn, và chỉ cho job xuất chạy khi quota đủ cho lô dự kiến.

Không giấu 507 trong job tổng

Job xuất nhiều phần thường báo một mã tổng. Nếu phần thứ tư hỏng mà job vẫn báo thành công một phần, bên nhận có thể xử lý dữ liệu thiếu. Job nên ghi rõ phần nào đã lên, phần nào hỏng vì 507, và đánh dấu cả lô là chưa đủ cho tới khi mọi phần lên được.

Đầu ra nghiệm thu của HTTP 507 Insufficient Storage: bảng hop và phép thử sau giải phóng

Phần này gom tiêu chí và giới hạn.

Danh sách kiểm tra

Bảng hop response

Pipeline đạt khi mọi dòng dưới đây đúng.

• Mỗi phản hồi ghi được đọc Server, Via và thân lỗi.
• 507 có precondition được log và phân loại quota hay ổ vật lý.
• 507 không nằm trong danh sách retry tự động.
• Có bước giải phóng dung lượng hoặc xin nâng hạn mức trước khi thử lại.
• Thử lại sau 507 là quyết định chủ động, có ghi log.
• Tệp dở được kiểm và xóa trước khi ghi lại.
• Quota được đọc định kỳ và có ngưỡng cảnh báo.

Những gì lab chưa chạy

Chưa thử Nextcloud, SharePoint hay máy chủ WebDAV thật. Chưa thử COPY, MOVE, PROPPATCH nhận 507. Chưa thử precondition sufficient-disk-space, ghi dở, kho lưu phiên bản. Chưa thử HTTPS và proxy CONNECT, khi đó proxy không thấy được nội dung phản hồi. Cấu hình retry loại 507 là ví dụ chưa chạy.

Chạy lại với kho thật

Tạo một thư mục thử trên kho, đọc quota bằng PROPFIND. Nếu kho cho phép đặt quota thấp cho thư mục thử, lặp lại bốn lần PUT như lab. Nếu không, chỉ kiểm phần đọc quota và cách kho trả lỗi khi có sự cố, rồi cập nhật hàm hop theo chuỗi Server thật.

Proxy ở đâu trong luồng

Proxy nằm giữa pipeline và kho, chỉ chuyển tiếp. Khi kho chỉ nhận kết nối từ dải IP đã đăng ký tại Việt Nam, anh em có thể mua proxy tại trang chủ ProxyVN để có IP tĩnh cho danh sách cho phép. Proxy không tăng dung lượng kho. Vai trò của proxy có ở bài Web Scraping proxy là gì, header Via có ở bài Via header, cách ghi chuỗi cấu hình có ở bài định dạng proxy.

Với HTTPS qua CONNECT

Khi kho dùng HTTPS và proxy đi theo kiểu CONNECT, proxy chỉ thấy luồng mã hóa. Proxy không thêm Via vào phản hồi, cũng không đọc được mã. Mã 507 và mọi header đến thẳng từ kho. Trường hợp này càng ít lý do nghi proxy, trừ khi CONNECT thất bại, lúc đó không có mã HTTP từ kho.

HTTP 507 Insufficient Storage: câu hỏi thường gặp

Các câu dưới đây gom những điểm hay bị hỏi.

507 có phải proxy hết băng thông không?

Không, trong mọi ca của lab. 507 mang Server của kho và thân lỗi DAV. Proxy hết lưu lượng trả mã khác, tùy nhà cung cấp.

Có nên thử lại 507 ngay không?

Không. RFC 4918 nói không tự lặp lại. Lab thử lại ba lần, kho vẫn đầy, tốn thêm ba lần gửi tệp.

Làm sao biết còn bao nhiêu chỗ?

Đọc DAV:quota-available-bytes bằng PROPFIND. Lab đọc được số byte còn lại sau mỗi lần ghi.

quota-not-exceeded và sufficient-disk-space khác gì?

Cái đầu là vượt hạn mức tài khoản, cái sau là ổ vật lý hết chỗ. Hai người sửa khác nhau.

Đọc quota trước có thay được xử lý 507 không?

Không. RFC 4331 nói quota chỉ là ước lượng. Vẫn phải xử lý 507.

502 và 507 cùng xuất hiện thì sao?

Đọc Server của từng phản hồi. Trong lab, 502 do proxy sinh khi origin chết, 507 do kho sinh khi đầy.

MKCOL có báo 507 không?

Có thể. RFC 4918 liệt kê 507 cho MKCOL. Lab chỉ từ chối MKCOL khi quota chạm trần, server thật có thể khác.

HTTP 507 Insufficient Storage và những điều cần nhớ

HTTP 507 Insufficient Storage là kho báo hết chỗ, không phải proxy hỏng. Đọc Server, Via và precondition để xác định hop, bỏ 507 khỏi retry tự động, giải phóng dung lượng rồi mới thử lại một lần. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em theo dõi quota để tránh HTTP 507 Insufficient Storage.