HTTP Status Codes

1xx Informational

Các mã 1xx thường là các phản hồi tạm thời để chia sẻ thông tin về trạng thái kết nối. Chúng không nhằm mục đích cho hành động yêu cầu hoặc phản hồi cuối cùng. Các yêu cầu từ máy chủ:

  • Các phản hồi đều kết thúc bằng dòng trống đầu tiên sau dòng trạng thái.

  • Không được sử dụng cho HTTP 1.0. Máy chủ gốc không bao giờ nên gửi phản hồi 1xx đến máy khách HTTP 1.0.

  • CMC Cloud CDN sẽ chuyển tiếp tất cả các phản hồi này và không bao giờ tự tạo ra các phản hồi này.

100 Continue ( RFC7231 )

Xác nhận yêu cầu ban đầu để gửi phần body phản hồi. Máy chủ gốc sẵn sàng chấp nhận yêu cầu (dựa trên các tiêu đề yêu cầu). Mã này được trả về trước khi máy khách gửi phần body phản hồi. Điều này ngăn chặn máy khách gửi dữ liệu không cần thiết hoặc không sử dụng được. Yêu cầu từ máy chủ: Nếu máy khách gửi tiêu đề Expect: 100-continue, máy chủ phải phản hồi ngay lập tức bằng mã 100 Continue và tiếp tục đọc từ luồng đầu vào hoặc gửi mã phản hồi khác. CMC Cloud CDN sử dụng các kết nối Keep-Alive nên phản hồi này thường không cần thiết.

101 Switching Protocols ( RFC7231)

Máy chủ gốc chấp nhận yêu cầu của máy khách để chuyển đổi giao thức. Yêu cầu của máy khách hoặc chứa tiêu đề Upgrade trong trường tiêu đề hoặc có sự thay đổi trong giao thức ứng dụng đang được sử dụng trên kết nối này. Nếu sử dụng trường tiêu đề Upgrade, máy chủ đã đồng ý nâng cấp lên một giao thức có mức độ ưu tiên cao hơn trong danh sách ưu tiên của máy khách so với giao thức hiện đang được sử dụng. Máy chủ gốc cũng phải phản hồi với trường tiêu đề Upgrade để chỉ ra giao thức mới mà kết nối đang được chuyển đổi sang. Sự chuyển đổi này được giả định sẽ có lợi cho cả máy khách và máy chủ. Trường hợp sử dụng phổ biến nhất là với WebSockets.

102 Processing ( RFC2518 )

Server has received the client’s completed response, but is expecting to take more time to process ( e.g. > 20 seconds). The server must send a final response after the request has been completed. Used for only HTTP 1.1 and higher.

2xx Success

Các mã 2xx chỉ ra sự thành công — nghĩa là hành động của máy khách đã được nhận, hiểu và chấp nhận.

200 - OK

Phản hồi 200 có nghĩa là yêu cầu đã thành công.

Nội dung phản hồi sẽ thay đổi dựa trên phương thức yêu cầu:

  • GET: Tiêu đề và dữ liệu tương ứng với tài nguyên yêu cầu

  • HEAD: Chỉ có tiêu đề tương ứng với tài nguyên yêu cầu

  • POST: Trạng thái hoặc kết quả thu được từ hành động

Phản hồi 200 nên luôn có một payload (nội dung phản hồi), nhưng không bắt buộc. Đôi khi, máy chủ gốc có thể tạo ra phản hồi 200 với độ dài bằng không. Để tuân thủ tiêu chuẩn RFC, máy chủ nên tạo ra mã 204 (ngoại trừ trường hợp CONNECT).

201 - Created

Phản hồi 201 có nghĩa là yêu cầu đã thành công và một hoặc nhiều tài nguyên mới đã được tạo ra.

Thông thường, bạn sẽ tìm thấy vị trí của tài nguyên mới trong phản hồi của máy chủ (hoặc trong tiêu đề Location hoặc URI của yêu cầu).

206 - Partial content

Phản hồi 206 có nghĩa là yêu cầu đã thành công một phần. Sử dụng phản hồi này để giảm độ trễ khi máy khách đang xử lý các tệp lớn có thể yêu cầu tải xuống chia nhỏ hoặc bị gián đoạn.

Yêu cầu này cũng nên trả về một trong hai:

  • Một payload một phần bao gồm tiêu đề Content-Range chỉ ra phạm vi và dữ liệu có trong phạm vi đó

  • Một payload đa phần không bao gồm tiêu đề Content-Range ở phản hồi HTTP cấp cao nhất, nhưng bao gồm các tiêu đề Content-Type và Content-Range trên từng phần riêng lẻ

3xx Redirection

4xx Client Error

Các mã 4xx thường là phản hồi lỗi chỉ ra vấn đề từ phía máy khách (client), có thể là sự cố mạng.

400 Bad Request ( RFC7231)

Máy khách đã không gửi yêu cầu đúng tới máy chủ. Đây là lỗi từ phía máy khách: cú pháp yêu cầu không đúng, yêu cầu không hợp lệ, khung thông điệp, hoặc định tuyến yêu cầu gây hiểu lầm. Ví dụ, nếu yêu cầu chứa một ký tự đặc biệt không được mã hóa URL đúng cách (hoặc mã hóa phần trăm), mã lỗi HTTP 400 sẽ được trả về.

401 Unauthorized ( RFC7235)

Yêu cầu không được gửi với thông tin xác thực phù hợp.

Máy chủ phải gửi ít nhất một thử thách dưới dạng trường tiêu đề WWW-Authenticate theo mục 4.1. Máy khách có thể gửi yêu cầu thứ hai với cùng thông tin xác thực và nếu thử thách giống với thử thách trước đó, máy chủ sẽ cung cấp một thực thể để giúp máy khách xác định thông tin xác thực cần thiết.

403 Forbidden ( [RFC7231]](https://tools.ietf.org/html/rfc7231))

Nếu bạn thấy lỗi 403 mà không có thương hiệu của CDN Cloud CMC, lỗi này luôn được trả về trực tiếp từ máy chủ web gốc, không phải từ CMC Cloud CDN, và thường liên quan đến các quy tắc quyền trên máy chủ của bạn. Các lý do chính cho lỗi này là:

  • Các quy tắc quyền mà bạn đã đặt trên máy chủ web gốc (ví dụ trong Apache .htaccess)

  • Các quy tắc của Mod_security

  • Các quy tắc chặn IP.

404 Not Found ( RFC7231)

Điều này thường có nghĩa là máy chủ không thể tìm thấy tài nguyên.

Các lỗi này thường xảy ra khi ai đó nhập sai URL trên trang của bạn, khi có liên kết bị hỏng từ trang khác, khi một trang trước đây tồn tại bị di chuyển hoặc bị xóa, hoặc có lỗi khi công cụ tìm kiếm lập chỉ mục trang web của bạn. Đối với một trang web thông thường, các lỗi này chiếm khoảng 3% tổng số lượt xem trang, nhưng thường không được theo dõi bởi các nền tảng phân tích truyền thống như Google Analytics.

Chủ sở hữu trang web thường triển khai một trang tùy chỉnh để phục vụ khi lỗi này được tạo ra.

CMC Cloud CDN không tạo ra các lỗi 404 cho các trang web của khách hàng, chúng tôi chỉ proxy yêu cầu từ máy chủ gốc. Khi thấy lỗi 404 cho trang web sử dụng CMC Cloud CDN, bạn nên liên hệ với nhà cung cấp dịch vụ lưu trữ của mình để được giúp đỡ.

405 Method Not Allowed ( RFC7231)

Phương thức yêu cầu được sử dụng không được hỗ trợ.

Máy chủ gốc cũng phải cung cấp một tiêu đề Allow với danh sách các phương thức được hỗ trợ cho tài nguyên đó. Ví dụ, một yêu cầu POST trên một tài nguyên không thay đổi, do đó chỉ chấp nhận GET.

406 Not Acceptable ( RFC7231)

Tài nguyên không có sẵn tại máy chủ gốc theo các tiêu đề đàm phán đã được thiết lập trước đó (ví dụ: thông qua các tiêu đề Accept-CharsetAccept-Language).

Mã trạng thái này có thể được thay thế bằng cách đơn giản phục vụ phương thức ít được ưa chuộng hơn cho User-Agent thay vì tạo ra lỗi này.

408 Request Timeout ( RFC7231)

Máy chủ gốc không nhận được yêu cầu hoàn chỉnh trong khoảng thời gian mà nó coi là hợp lý.

Ngụ ý rằng máy chủ không muốn chờ và tiếp tục kết nối. Không được sử dụng nhiều vì các máy chủ thường chọn sử dụng tùy chọn kết nối “close”.

​​409 Conflict ( RFC7231)

Yêu cầu không hoàn thành vì xung đột với trạng thái hiện tại của tài nguyên. Thường xảy ra trên yêu cầu PUT khi nhiều máy khách cố gắng chỉnh sửa cùng một tài nguyên.

  • Máy chủ nên tạo ra một payload bao gồm đủ thông tin để máy khách nhận ra nguồn gốc của xung đột.

  • Máy khách có thể và nên thử lại yêu cầu một lần nữa.

413 Payload Too Large ( RFC7231)

Máy chủ từ chối xử lý yêu cầu vì payload được gửi từ máy khách lớn hơn mức máy chủ muốn chấp nhận. Máy chủ có thể lựa chọn đóng kết nối.

Nếu sự từ chối này chỉ xảy ra tạm thời, máy chủ nên gửi tiêu đề Retry-After để chỉ ra thời gian máy khách nên thử lại yêu cầu.

414 URI Too Long ( RFC7231)

Máy chủ từ chối xử lý yêu cầu vì URI quá dài. Ví dụ, nếu một máy khách cố gắng thực hiện yêu cầu GET với một URI dài bất thường sau một POST, điều này có thể được coi là rủi ro bảo mật và sẽ tạo ra mã 414.

415 Unsupported Media Type ( RFC7231)

Máy chủ từ chối xử lý định dạng của payload hiện tại. Một cách để xác định và khắc phục vấn đề này là xem các tiêu đề Content-Type hoặc Content-Encoding được gửi trong yêu cầu của máy khách.

417 Expectation Failed ( RFC7231)

Máy chủ không thể đáp ứng các yêu cầu được chỉ định trong tiêu đề Expect của yêu cầu máy khách.

429 Too Many Requests ( RFC6585)

Máy khách đã gửi quá nhiều yêu cầu trong khoảng thời gian nhất định theo máy chủ. Thường được biết đến như là “rate-limiting”. Máy chủ có thể phản hồi với thông tin cho phép người yêu cầu thử lại sau một khoảng thời gian cụ thể.

499 Client Close Request

Mã phản hồi cụ thể của nginx để chỉ ra khi kết nối bị đóng bởi máy khách trong khi máy chủ vẫn đang xử lý yêu cầu, khiến máy chủ không thể gửi mã trạng thái trở lại.

Để cung cấp thêm ngữ cảnh, một kết nối TCP phải được thiết lập giữa CMC Cloud CDN và máy chủ gốc của trang web trước khi bất kỳ giao thức cao hơn nào (trong trường hợp này là HTTP) bắt đầu "cuộc trò chuyện". Để thiết lập kết nối, TCP sử dụng một quy trình bắt tay ba bước:

  • SYN: CMC Cloud CDN gửi ba gói SYN đến máy chủ gốc.

  • SYN+ACK: Đáp lại, máy chủ gốc trả lời bằng SYN+ACK.

  • ACK: Cuối cùng, CMC Cloud CDN gửi lại một ACK cho máy chủ gốc.

Tại thời điểm này, cả CMC Cloud CDN và máy chủ gốc đã nhận được xác nhận của kết nối và giao tiếp được thiết lập. Tuy nhiên, nếu máy chủ gốc không gửi SYN+ACK trở lại CMC Cloud CDN trong vòng 15 giây, CMC Cloud CDN sẽ thử lại một lần nữa (thời gian chờ thêm 15 giây nữa).

Vì vậy, tùy thuộc vào giá trị thời gian chờ phía máy khách, sẽ có 3 kịch bản khác nhau cùng với mỗi mã trạng thái được tạo ra:

  • Nếu máy khách có thời gian chờ ngắn hơn (dưới 30 giây), họ sẽ từ bỏ kết nối và do đó CMC Cloud CDN ghi lại lỗi 499.

  • Nếu máy khách có thời gian chờ dài hơn (hơn 30 giây), khi kết nối TCP được thiết lập thành công, giao dịch HTTP sẽ tiếp tục như bình thường. Trong trường hợp này, CMC Cloud CDN trả về mã trạng thái bình thường (HTTP 200).

  • Nếu máy khách có thời gian chờ dài hơn và CMC Cloud CDN không thể thiết lập bắt tay TCP với máy chủ gốc, chúng tôi sẽ trả về HTTP 522.

5xx Server Error

Khi khắc phục hầu hết các lỗi 5xx, hành động trước tiên cần liên hệ với nhà cung cấp dịch vụ hosting hoặc quản trị viên trang web để khắc phục sự cố và thu thập dữ liệu lỗi.

Khi liên hệ với đội ngũ hỗ trợ, hãy cung cấp các thông tin sau:

  1. Thông báo cụ thể về mã lỗi 5xx

  2. Thời gian xảy ra lỗi 5xx

  3. URL bị lỗi HTTP 5xx (ví dụ: https://www.example.com/images/icons/image1.png)

Nguyên nhân lỗi không phải lúc nào cũng được tìm thấy trong Log của Origin Server. Kiểm tra Log của tất cả các thiết bị như Loadbalancer, caches, proxies, firewall giữa CMC Cloud CDN và Origin Server.

Error 500: internal server error

Lỗi 500 thường là sự cố với origin web server. Error establishing database connection là thông báo lỗi HTTP 500 phổ biến do origin web server tạo ra. Hãy liên với đội ngũ hỗ trợ để giải quyết vấn đề.

Error 502 bad gateway or error 504 gateway timeout

Lỗi HTTP 502 và 504 xảy ra khi lỗi CMC Cloud CDN không thể thiết lập liên kết với Origin web Server. Có 2 nguyên nhân có thể xảy ra:

  • (Nguyên nhân phổ biến) 502/504 từ Origin web Server

  • 502/504 từ CMC Cloud CDN

502/504 từ Origin web Server

Lỗi này thông thường trên CDN sẽ trả lại trang thông tin lỗi giống với trang thông tin lỗi của Origin

Để khắc phục các lỗi này người quản trị cần:

  • Đảm bảo Origin phản hồi các request về hostname và domain trong URL của khách truy cập đã tạo ra lỗi 502 hoặc 504

  • Điều tra tình trạng máy chủ quá tải, sự cố hoặc lỗi mạng.

  • Xác định ứng dụng đã time out hoặc bị chặn.

502/504 từ CMC Cloud CDN

Trang thông tin lỗi khi được trả từ CMC Cloud CDN sẽ như dưới:

Nếu nhận được thông báo như trên thì vui lòng liên hệ với đội ngũ hỗ trợ để được hỗ trợ nhanh.

Last updated