Tra Cứu Mã HTTP Status

Mã HTTP Status — Tham Chiếu Đầy Đủ Từ 100 đến 511

Mỗi phản hồi HTTP từ server bao gồm mã ba chữ số cho client biết điều gì đã xảy ra. Mã được nhóm thành năm danh mục: 1xx (thông tin), 2xx (thành công), 3xx (chuyển hướng), 4xx (lỗi client), và 5xx (lỗi server). Tham chiếu này liệt kê tất cả 60+ mã đã đăng ký với tên, mô tả, tình huống sử dụng phổ biến, và link tới RFC định nghĩa. Lọc theo danh mục, tìm theo số hoặc từ khóa, hoặc sao chép bất kỳ mã nào vào clipboard cho tài liệu, báo cáo bug, hoặc commit message.

Khác nhau giữa 401 Unauthorized và 403 Forbidden là gì?

Hai mã trông giống nhau nhưng nghĩa khác nhau:

- **401 Unauthorized** — client chưa xác thực, hoặc xác thực thất bại. Cách sửa là đăng nhập hoặc gửi token hợp lệ. Phản hồi nên bao gồm header WWW-Authenticate báo client cách làm. Khó hiểu thay, dù tên là vậy, 401 nghĩa là 'chưa xác thực'.

- **403 Forbidden** — client đã xác thực nhưng không có quyền cho tài nguyên cụ thể này. Thử lại với cùng credential sẽ không sửa được; user đơn giản thiếu quyền truy cập.

Mẫu phổ biến trong ứng dụng nhạy cảm bảo mật là trả 404 Not Found thay vì 403 để tránh tiết lộ rằng tài nguyên hạn chế thậm chí tồn tại. Ví dụ, GitHub trả 404 cho repo riêng tư bạn không có quyền, không phải 403.

Nên dùng 301 hay 308 cho redirect vĩnh viễn?

Tùy thuộc vào method HTTP. Hai mã có ý nghĩa ngữ nghĩa giống nhau (cả hai đều là redirect vĩnh viễn), nhưng hành xử khác khi yêu cầu gốc là POST/PUT/DELETE:

- **301 Moved Permanently** — RFC 9110 cho phép rõ client đổi method yêu cầu thành GET khi theo 301. Lịch sử, hầu hết trình duyệt luôn làm vậy, kể cả cho POST. Chỉ dùng 301 cho redirect GET.

- **308 Permanent Redirect** — giữ method gốc rõ ràng. POST vẫn là POST, DELETE vẫn là DELETE. Dùng 308 khi redirect phải làm việc cho endpoint API.

Với website chủ yếu redirect yêu cầu GET (vd HTTP → HTTPS, www → non-www), 301 ổn và hỗ trợ tốt hơn ở client cũ. Cho API và form, ưu tiên 308.

Cùng phân biệt tồn tại cho redirect tạm thời: 302 (lỏng) vs 307 (giữ method).

Khi nào 422 Unprocessable Content phù hợp?

422 là mã đúng khi cú pháp yêu cầu hợp lệ (JSON đúng dạng, content-type đúng) nhưng nội dung *ngữ nghĩa* sai. Ví dụ kinh điển là form đăng ký nơi:

- JSON parse đúng → không phải 400
- Trường email có mặt → không phải lỗi thiếu trường
- Nhưng địa chỉ email sai dạng (vd 'not-an-email') → 422 Unprocessable Content

Ngược với 400 Bad Request nên dành cho:

- JSON sai dạng (lỗi parse)
- Thiếu trường bắt buộc
- Header content-type sai

Thực tế, nhiều API dùng 400 cho mọi thứ phía client, và điều đó cũng chấp nhận được. Phân biệt quan trọng khi bạn muốn cho client cách lập trình để phân biệt 'sửa data' với 'sửa định dạng yêu cầu'. GitHub, Stripe, và hầu hết REST API hiện đại dùng 422 cho lỗi validation.

Mã đúng cho rate limiting là gì?

**429 Too Many Requests** là câu trả lời chuẩn (RFC 6585). Phản hồi nên bao gồm:

- Header **Retry-After** — hoặc giây (`Retry-After: 60`) hoặc ngày HTTP — báo client khi nào thử lại.
- Body tùy chọn giải thích giới hạn. JSON như `{"error": "rate_limit_exceeded", "retry_after": 60}` phổ biến.
- Tùy chọn bộ ba header **X-RateLimit-Limit**, **X-RateLimit-Remaining**, **X-RateLimit-Reset** cho client theo dõi hạn ngạch. (Không chuẩn hóa nhưng được áp dụng rộng rãi bởi GitHub, Stripe, Twitter, v.v.)

Cho bảo vệ kiểu DDoS nơi bạn muốn drop yêu cầu im lặng, trả 503 Service Unavailable với Retry-After dài đôi khi được dùng làm thay thế.

Tránh dùng 503 cho rate-limiting thông thường vì nó báo client rằng *server* đang lỗi, không phải client. 429 là tín hiệu đúng rằng 'bạn đang gửi quá nhiều, chậm lại'.

418 'I'm a teapot' có thật không?

Có, kiểu vậy. RFC 2324 định nghĩa HyperText Coffee Pot Control Protocol (HTCPCP), một RFC Cá tháng Tư từ 1998 đặc tả giao thức pha cà phê qua HTTP. Bất kỳ nỗ lực pha cà phê với ấm trà nào trả 418 I'm a teapot.

Mã chính thức đăng ký với IANA nhưng được giữ như trò đùa. Năm 2017 có nỗ lực bán nghiêm túc gỡ nó khỏi thư viện server (Node.js tạm thời gỡ hỗ trợ); cộng đồng đẩy lại, và hầu hết stack giữ. Giờ nó được an toàn cố thủ như phần của văn hóa HTTP.

Ứng dụng thực tế cho 418 hạn chế:

- **Trò đùa Cá tháng Tư** — một số site trả 418 từ endpoint /teapot.
- **Easter egg** trong tài liệu API.
- **Phát hiện scraper tự động** — một số site trả 418 cho pattern traffic nghi ngờ vì client thật sẽ không mong đợi.

Đừng dùng 418 trong production cho lỗi thực — client sẽ không biết làm gì. Bám vào mã 4xx/5xx chuẩn.

500 nghĩa là gì và khác 503 thế nào?

**500 Internal Server Error** là catch-all chung: server gặp điều kiện bất ngờ (bug, exception chưa xử lý) và không thể hoàn thành yêu cầu. Hàm ý là thử lại ngay có thể không giúp — có gì đó sai phía server.

**503 Service Unavailable** cụ thể hơn: dịch vụ tạm thời sập, thường vì quá tải, bảo trì có kế hoạch, hoặc autoscaling chậm. Hàm ý là thử lại sau (thường với header **Retry-After** cho biết khi nào) sẽ thành công.

Vài tinh tế:

- Load balancer trả 503 nghĩa upstream không truy cập được. Xem log lỗi LB.
- Ứng dụng trả 503 nghĩa đang cố ý từ chối yêu cầu (chế độ bảo trì, circuit breaker tripped).
- 503 không bao giờ nên được trả bởi crash app — đó là lãnh địa 500.
- Cloudflare và CDN khác có mã 5xx riêng (520, 521, 522, 523, 524, 525, 526, 527) cho lỗi upstream cụ thể. Không đăng ký IANA nhưng xuất hiện trong dev tool trình duyệt.

Tại sao dải 1xx hiếm thấy trong tools?

Mã 1xx là trung gian — chúng được gửi *trước* phản hồi cuối. Hầu hết tool (trình duyệt, curl, Postman) không bộc lộ chúng vì khi phản hồi cuối 2xx/3xx/4xx/5xx đến, ngữ cảnh 1xx đã mất.

Ba cái bạn thỉnh thoảng thấy:

- **100 Continue** — gửi khi client dùng `Expect: 100-continue` để hỏi server có chấp nhận upload lớn trước khi gửi body không. Giúp tránh lãng phí bandwidth trên POST bị từ chối.
- **101 Switching Protocols** — gửi trong quá trình nâng cấp giao thức, phổ biến nhất là handshake WebSocket. Dev tool trình duyệt hiển thị trong tab Network cho mọi kết nối WebSocket đang hoạt động.
- **103 Early Hints** — mới hơn (2017, RFC 8297). Cho phép server gửi gợi ý `Link: preload` trước phản hồi cuối, để trình duyệt bắt đầu tải CSS, JS, và font song song. Dùng bởi Cloudflare và Fastly.

102 Processing tồn tại (RFC 2518 cho WebDAV) nhưng hầu như không dùng ngoài server WebDAV chuyên biệt.

Các mã này đến từ đâu?

Mã HTTP status được định nghĩa qua nhiều RFC:

- **RFC 9110** (Tháng 6/2024) — đặc tả ngữ nghĩa HTTP hiện tại, định nghĩa mã cơ sở 1xx, 2xx, 3xx, 4xx, 5xx. Thay RFC 7231 năm 2024.
- **RFC 4918** — WebDAV (207 Multi-Status, 422 Unprocessable Content [giờ trong 9110], 423 Locked, 424 Failed Dependency, 507 Insufficient Storage).
- **RFC 6585** — Mã HTTP status bổ sung (428, 429, 431, 511).
- **RFC 7538** — 308 Permanent Redirect.
- **RFC 7725** — 451 Unavailable For Legal Reasons.
- **RFC 8297** — 103 Early Hints.
- **RFC 8470** — 425 Too Early (TLS 1.3).
- **RFC 2324** — 418 I'm a teapot (đùa Cá tháng Tư).
- **IANA HTTP Status Code Registry** — danh sách chính thức mọi mã đã đăng ký.

Mỗi card trong tham chiếu này link tới RFC định nghĩa mã đó, để bạn luôn có thể đi tới nguồn chính thức cho trường hợp biên.

Tính Năng Chính

• Mọi mã HTTP status đã đăng ký IANA (60+) bao phủ 100 đến 511
• Mô tả chi tiết cho 25 mã phổ biến nhất (200, 301, 304, 401, 403, 404, 429, 500, 503, v.v.)
• Tìm theo số mã hoặc từ khóa qua tên và mô tả
• Lọc theo danh mục: 1xx Thông tin, 2xx Thành công, 3xx Chuyển hướng, 4xx Lỗi Client, 5xx Lỗi Server
• Chỉ báo danh mục mã màu cho nhận diện trực quan tức thì
• Link trực tiếp tới RFC định nghĩa cho mỗi mã (RFC 9110, RFC 6585, v.v.)
• Nút truy cập nhanh cho bốn mã được tìm nhiều nhất (200, 301, 404, 500)
• Sao chép bất kỳ mã status nào vào clipboard với một cú nhấp cho báo cáo bug và tài liệu
• Ví dụ tình huống sử dụng giải thích khi nào mỗi mã phù hợp
• Bao phủ bổ sung hiện đại: 103 Early Hints, 308 Permanent Redirect, 425 Too Early, 451 Legal
• Bao gồm 418 I'm a teapot của RFC 2324 cho đầy đủ
• JavaScript thuần — không thư viện ngoài
• Hoạt động offline sau lần tải đầu
• Bố cục lưới responsive cho di động và desktop
• 100% phía client — không yêu cầu nào được tra cứu