| Mã trạng thái HTTP |
Nghĩa của mã trạng thái |
| 100 |
Khách hàng nên tiếp tục gửi yêu cầu. Phản hồi tạm thời này được sử dụng để thông báo cho khách hàng rằng một phần yêu cầu của họ đã được máy chủ nhận và vẫn chưa bị từ chối. Khách hàng nên tiếp tục gửi phần còn lại của yêu cầu, hoặc nếu yêu cầu đã hoàn thành thì có thể bỏ qua phản hồi này. Máy chủ phải gửi phản hồi cuối cùng cho khách hàng sau khi hoàn thành yêu cầu. |
| 101 |
Máy chủ đã hiểu yêu cầu của khách hàng và sẽ thông báo cho khách hàng bằng tiêu đề tin nâng cấp để sử dụng giao thức khác để hoàn thành yêu cầu này. Sau khi gửi dòng trống cuối cùng của phản hồi này, máy chủ sẽ chuyển sang các giao thức được định nghĩa trong tiêu đề tin nâng cấp. Chỉ nên thực hiện các biện pháp tương tự khi việc chuyển sang giao thức mới mang lại lợi ích hơn. Ví dụ, chuyển sang một phiên bản HTTP mới có lợi hơn phiên bản cũ, hoặc chuyển sang một giao thức trực tiếp và đồng bộ để truyền tải các tài nguyên có tính năng như vậy. |
| 102 |
Mã trạng thái mở rộng từ WebDAV (RFC 2518), đại diện cho việc xử lý sẽ tiếp tục được thực hiện. |
| 200 |
Yêu cầu đã được thực hiện thành công, tiêu đề phản hồi hoặc dữ liệu mong muốn từ yêu cầu sẽ được trả về với phản hồi này. |
| 201 |
Yêu cầu đã được thực hiện và một tài nguyên mới đã được tạo ra theo yêu cầu, và URI của nó đã được trả về cùng với thông tin tiêu đề Location. Nếu tài nguyên yêu cầu không thể được tạo ra kịp thời, nên trả về '202 Accepted'. |
| 202 |
Máy chủ đã chấp nhận yêu cầu, nhưng chưa xử lý. Yêu cầu cuối cùng có thể bị từ chối hoặc không được thực hiện. Trong trường hợp các hoạt động bất đồng bộ, không có cách nào thuận tiện hơn việc gửi mã trạng thái này. Mục đích của việc trả về phản hồi có mã trạng thái 202 là cho phép máy chủ chấp nhận yêu cầu cho các quy trình khác (ví dụ như một hoạt động dạng lô chỉ thực hiện một lần mỗi ngày), mà không cần giữ kết nối liên tục với máy chủ cho đến khi tất cả các hoạt động dạng lô hoàn thành. Phản hồi chấp nhận xử lý yêu cầu và trả về mã trạng thái 202 nên bao gồm một số thông tin chỉ ra trạng thái xử lý hiện tại, cũng như một con trỏ đến trình giám sát trạng thái xử lý hoặc dự đoán trạng thái, để người dùng có thể ước tính xem hoạt động đã hoàn thành hay chưa. |
| 203 |
Máy chủ đã xử lý yêu cầu thành công, nhưng thông tin tiêu đề của thực thể trả về không giống như tập hợp xác định có hiệu lực trên máy chủ gốc, mà là từ một bản sao địa phương hoặc bên thứ ba. Thông tin hiện tại có thể là một phần hoặc tập hợp siêu của phiên bản gốc. Ví dụ, thông tin siêu dữ liệu chứa tài nguyên có thể khiến máy chủ gốc biết siêu thông tin. Việc sử dụng mã trạng thái này không phải là cần thiết và chỉ phù hợp trong trường hợp mà phản hồi sẽ trở lại với mã trạng thái 200 OK nếu không sử dụng mã trạng thái này. |
| 204 |
Máy chủ đã xử lý yêu cầu thành công, nhưng không cần trả lại bất kỳ nội dung nào và hy vọng trả về thông tin siêu thông tin đã cập nhật. Phản hồi có thể trả về thông tin siêu thông tin mới hoặc đã cập nhật dưới dạng tiêu đề thực thể. Nếu có thông tin tiêu đề này, nó nên phản ánh các biến được yêu cầu. Nếu khách hàng là trình duyệt, thì trình duyệt của người dùng nên giữ trang đã gửi yêu cầu mà không có sự thay đổi nào về hiển thị tài liệu, ngay cả khi theo tiêu chuẩn thông tin siêu được mới hoặc đã cập nhật nên được áp dụng vào hiển thị tài liệu trực diện của trình duyệt. Vì phản hồi 204 bị cấm bao gồm bất kỳ nội dung tin nhắn nào, nên nó luôn kết thúc bằng dòng trống đầu tiên sau tiêu đề. |
| 205 |
Máy chủ đã xử lý yêu cầu thành công và không trả về nội dung nào. Tuy nhiên, khác với phản hồi 204, phản hồi với mã trạng thái này yêu cầu người yêu cầu đặt lại hiển thị tài liệu. Phản hồi này chủ yếu được sử dụng để đặt lại mẫu ngay lập tức sau khi nhận được đầu vào của người dùng, để người dùng có thể dễ dàng bắt đầu nhập lại một lần nữa. Giống như phản hồi 204, phản hồi này cũng cấm chứa nội dung tin nhắn và kết thúc bằng dòng trống đầu tiên sau tiêu đề. |
| 206 |
Máy chủ đã xử lý thành công một phần yêu cầu GET. Các công cụ tải xuống HTTP như FlashGet hoặc Thunder sử dụng phản hồi này để thực hiện việc tải xuống tiếp theo từ điểm khôi phục hoặc phân chia một tài liệu lớn thành nhiều phần tải xuống đồng thời. Yêu cầu này phải chứa thông tin tiêu đề Range chỉ ra miền nội dung mà khách hàng muốn nhận và có thể chứa If-Range như một điều kiện yêu cầu. Phản hồi phải bao gồm các miền tiêu đề sau: Content-Range để chỉ ra miền nội dung được trả về trong phản hồi này; nếu là tải xuống nhiều phần với Content-Type là multipart/byteranges, thì mỗi phần multipart nên chứa miền Content-Range để chỉ ra miền nội dung của phần đó. Nếu phản hồi chứa Content-Length, thì giá trị của nó phải khớp với số byte thực tế của miền nội dung mà nó trả về. Date, ETag và/hoặc Content-Location, nếu yêu cầu tương tự trước đó should return a 200 response. Expires, Cache-Control, và/hoặc Vary, nếu giá trị của chúng có thể khác với giá trị tương ứng của các phản hồi đã được lưu trữ trước đó cho các biến tương tự. Nếu yêu cầu này sử dụng xác thực bộ đệm mạnh với If-Range, thì phản hồi này không nên chứa bất kỳ tiêu đề thực thể nào khác; nếu yêu cầu này sử dụng xác thực bộ đệm yếu với If-Range, thì phản hồi này cấm chứa bất kỳ tiêu đề thực thể nào khác; điều này tránh sự không nhất quán giữa nội dung thực thể đã được lưu trữ và thông tin tiêu đề thực thể được cập nhật. Ngược lại, phản hồi này nên chứa tất cả các miền tiêu đề mà một phản hồi 200 nên trả về. Nếu tiêu đề ETag hoặc Last-Modified không khớp chính xác, bộ đệm khách hàng nên cấm kết hợp nội dung trả về có mã trạng thái 206 với bất kỳ nội dung nào đã được lưu trữ trước đó. |
| 207 |
Mã trạng thái mở rộng từ WebDAV (RFC 2518), đại diện cho các thông điệp sau đây sẽ là một thông điệp XML và có thể bao gồm một loạt mã phản hồi độc lập tùy thuộc vào số lượng yêu cầu con trước đó. |
| 300 |
Nguồn tài nguyên được yêu cầu có một loạt thông tin phản hồi có thể lựa chọn, mỗi cái có địa chỉ cụ thể và thông tin thương mại do trình duyệt điều khiển. Người dùng hoặc trình duyệt có thể tự chọn một địa chỉ ưa thích để chuyển hướng. Trừ khi đây là một yêu cầu HEAD, thì phản hồi nên bao gồm một thực thể chứa danh sách các thuộc tính và địa chỉ của nguồn tài nguyên, để người dùng hoặc trình duyệt có thể chọn địa chỉ chuyển hướng phù hợp nhất. Định dạng thực thể do định dạng được xác định bởi loại nội dung Content-Type. Trình duyệt có thể tự động đưa ra lựa chọn thích hợp nhất dựa trên định dạng phản hồi và khả năng của chính nó. Dĩ nhiên, quy định RFC 2616 không đề ra cách thức tự động lựa chọn này. Nếu máy chủ đã có một lựa chọn phản hồi ưa thích, thì URI phản hồi đó nên được chỉ rõ trong Location; trình duyệt có thể sử dụng giá trị Location này làm địa chỉ chuyển hướng tự động. Hơn nữa, trừ khi có chỉ định bổ sung, phản hồi này cũng có thể được lưu trữ. |
| 301 |
Nguồn tài nguyên được yêu cầu đã được di chuyển vĩnh viễn đến một vị trí mới, và bất kỳ tham chiếu nào đến nguồn tài nguyên này trong tương lai nên sử dụng một trong các URI được trả về với phản hồi này. Nếu có thể, khách hàng có chức năng chỉnh sửa liên kết nên tự động sửa đổi địa chỉ yêu cầu thành địa chỉ mà máy chủ phản hồi. Trừ khi có chỉ định bổ sung, phản hồi này cũng có thể được lưu trữ. URI vĩnh viễn mới nên được trả về trong miền Location của phản hồi. Trừ khi đây là một yêu cầu HEAD, thì thực thể phản hồi nên bao gồm một liên kết đến URI mới và mô tả ngắn gọn. Nếu đây không phải là một yêu cầu GET hoặc HEAD, thì trình duyệt cấm tự động chuyển hướng, trừ khi được sự xác nhận của người dùng, vì điều kiện yêu cầu có thể do đó mà thay đổi. Lưu ý: đối với một số trình duyệt sử dụng giao thức HTTP/1.0, nếu họ gửi yêu cầu POST và nhận được phản hồi 301, thì yêu cầu chuyển hướng tiếp theo sẽ trở thành phương thức GET. |
| 302 |
Tài nguyên yêu cầu hiện tại tạm thời phản hồi yêu cầu từ một URI khác. Do chuyển hướng như vậy là tạm thời, khách hàng nên tiếp tục gửi yêu cầu đến địa chỉ ban đầu. Phản hồi này chỉ có thể được lưu trữ nếu có chỉ định trong Cache-Control hoặc Expires. URI tạm thời mới nên được trả về trong miền Location của phản hồi. Trừ khi đây là một yêu cầu HEAD, thì thực thể phản hồi nên bao gồm một liên kết đến URI mới và mô tả ngắn gọn. Nếu đây không phải là một yêu cầu GET hoặc HEAD, thì trình duyệt cấm tự động chuyển hướng, trừ khi được sự xác nhận của người dùng, vì điều kiện yêu cầu có thể do đó mà thay đổi. Lưu ý: tuy RFC 1945 và RFC 2068 không cho phép khách hàng thay đổi phương thức yêu cầu khi chuyển hướng, nhưng nhiều trình duyệt hiện có xem phản hồi 302 như phản hồi 303 và sử dụng phương thức GET để truy cập URI được chỉ định trong Location mà bỏ qua phương thức yêu cầu ban đầu. Mã trạng thái 303 và 307 đã được thêm vào để làm rõ máy chủ mong đợi phản ứng gì từ khách hàng. |
| 303 |
Phản hồi tương ứng với yêu cầu hiện tại có thể tìm thấy tại một URI khác và khách hàng nên sử dụng phương thức GET để truy cập vào nguồn tài nguyên đó. Phương thức này tồn tại chủ yếu để cho phép redirect đầu ra của yêu cầu POST được kích hoạt bởi skrip đến một nguồn tài nguyên mới. URI mới này không phải là một tham chiếu thay thế cho tài nguyên gốc. Đồng thời, phản hồi 303 cấm lưu trữ. Dĩ nhiên, yêu cầu thứ hai (chuyển hướng) có thể được lưu trữ. URI mới nên được trả về trong miền Location của phản hồi. Trừ khi đây là một yêu cầu HEAD, thì thực thể phản hồi nên bao gồm một liên kết đến URI mới và mô tả ngắn gọn. Lưu ý: nhiều trình duyệt phiên bản trước HTTP/1.1 không thể hiểu chính xác mã trạng thái 303. Nếu cần xem xét tương tác với những trình duyệt này, mã trạng thái 302 nên đủ vì cách mà hầu hết trình duyệt xử lý phản hồi 302 chính là cách phải xử lý phản hồi 303 như yêu cầu quy định. |
| 304 |
Nếu khách hàng gửi một yêu cầu GET có điều kiện và yêu cầu này đã được cho phép, và nội dung của tài liệu (kể từ lần truy cập trước hoặc theo điều kiện yêu cầu) không thay đổi, thì máy chủ nên trả về mã trạng thái này. Phản hồi 304 cấm bao gồm tin nhắn thể, do đó nó luôn kết thúc bằng dòng trống đầu tiên sau tiêu đề. Phản hồi này phải bao gồm các thông tin tiêu đề sau: Date, trừ khi máy chủ này không có đồng hồ. Nếu máy chủ không có đồng hồ mà vẫn tuân thủ các quy tắc này, chương trình lưu trữ và khách hàng có thể tự thêm trường Date vào các tiêu đề phản hồi nhận được (như quy định trong RFC 2068), thì quy trình lưu trữ sẽ hoạt động bình thường. ETag và/hoặc Content-Location, nếu yêu cầu tương tự đó cũng cần phải trả về mã trạng thái 200. Expires, Cache-Control, và/hoặc Vary, nếu giá trị của chúng có thể khác với giá trị tương ứng của các phản hồi đã được lưu trữ trước đó cho các biến tương tự. Nếu yêu cầu này sử dụng xác thực bộ đệm mạnh với If-Range, phản hồi này không nên chứa bất kỳ tiêu đề thực thể nào khác; ngược lại (ví dụ, nếu một yêu cầu GET có điều kiện đã sử dụng xác thực bộ đệm yếu), phản hồi này cũng cấm chứa bất kỳ tiêu đề thực thể nào khác; điều này để tránh bất nhất giữa nội dung thực thể đã được lưu trữ và thông tin tiêu đề thực thể mới được cập nhật. Nếu một phản hồi 304 chỉ rõ rằng một thực thể cụ thể không được bộ đệm, thì hệ thống bộ đệm nên bỏ qua phản hồi này và lặp lại yêu cầu mà không có giới hạn điều kiện. Nếu nhận được một phản hồi 304 yêu cầu làm mới một mục bộ đệm, hệ thống bộ đệm phải hoàn toàn cập nhật mục đó để phản ánh tất cả các trường giá trị đã được cập nhật trong phản hồi này. |
| 305 |
Nguồn tài nguyên được yêu cầu phải được truy cập thông qua proxy được chỉ định. Thông tin URI nơi proxy được chỉ định sẽ được cung cấp trong miền Location, nhận viên cần gửi lại một yêu cầu riêng biệt qua proxy để truy cập tài nguyên tương ứng. Chỉ máy chủ gốc mới có thể thiết lập phản hồi 305. Lưu ý: RFC 2068 không chỉ định rõ phản hồi 305 là để chuyển hướng một yêu cầu riêng biệt, và chỉ có thể được thiết lập bởi máy chủ gốc. Bỏ qua những hạn chế này có thể gây ra hậu quả bảo mật nghiêm trọng. |
| 306 |
Trong các quy tắc mới nhất, mã trạng thái 306 không còn được sử dụng nữa. |
| 307 |
Tài nguyên yêu cầu hiện tại tạm thời phản hồi yêu cầu từ một URI khác. Do chuyển hướng như vậy là tạm thời, khách hàng nên tiếp tục gửi yêu cầu đến địa chỉ ban đầu. Phản hồi này chỉ có thể được lưu trữ nếu có chỉ định trong Cache-Control hoặc Expires. URI tạm thời mới nên được trả về trong miền Location của phản hồi. Trừ khi đây là một yêu cầu HEAD, thì thực thể phản hồi nên bao gồm một liên kết đến URI mới và mô tả ngắn gọn. Vì một số trình duyệt không nhận biết mã trạng thái 307, nên cần thêm thông tin cần thiết để người dùng có thể hiểu và gửi yêu cầu truy cập đến URI mới. Nếu đây không phải là một yêu cầu GET hoặc HEAD, thì trình duyệt cấm tự động chuyển hướng, trừ khi được xác nhận bởi người dùng, vì điều kiện yêu cầu có thể do đó mà thay đổi. |
| 400 |
1. Có lỗi ngữ nghĩa, yêu cầu hiện tại không thể được máy chủ hiểu. Trừ khi thực hiện sửa đổi, khách hàng không nên lặp lại yêu cầu này. 2. Tham số yêu cầu có lỗi. |
| 401 |
Yêu cầu hiện tại yêu cầu xác thực người dùng. Phản hồi này phải bao gồm thông tin WWW-Authenticate áp dụng cho tài nguyên được yêu cầu để yêu cầu thông tin người dùng. Khách hàng có thể lặp lại một yêu cầu chứa thông tin xác thực Authorization thích hợp. Nếu yêu cầu hiện tại đã chứa chứng chỉ Authorization, thì phản hồi 401 có nghĩa là xác thực của máy chủ đã từ chối phát sinh các chứng chỉ đó. Nếu phản hồi 401 chứa cùng một yêu cầu xác thực như phản hồi trước đó và trình duyệt đã cố gắng xác thực ít nhất một lần, thì trình duyệt nên hiển thị thông tin thực thể chứa trong phản hồi, vì thông tin thực thể này có thể chứa thông tin chẩn đoán liên quan. Xem RFC 2617. |
| 402 |
Mã trạng thái này được giữ lại cho yêu cầu có thể trong tương lai. |
| 403 |
Máy chủ đã hiểu yêu cầu nhưng từ chối thực hiện. Khác với phản hồi 401, xác thực không giúp ích gì và yêu cầu này cũng không nên được lặp lại. Nếu đây không phải là một yêu cầu HEAD và máy chủ muốn làm rõ lý do tại sao yêu cầu không thể được thực hiện, thì nên mô tả lý do từ chối trong thực thể. Dĩ nhiên, máy chủ cũng có thể trả về phản hồi 404 nếu không muốn để khách hàng biết bất kỳ thông tin nào. |
| 404 |
Yêu cầu không thành công, tài nguyên mong muốn không được tìm thấy trên máy chủ. Không có thông tin nào có thể cho người dùng biết trạng thái này là tạm thời hay vĩnh viễn. Nếu máy chủ biết tình hình, máy chủ nên sử dụng mã trạng thái 410 để thông báo rằng tài nguyên cũ đã không còn khả dụng vĩnh viễn vì một số vấn đề về cấu hình nội bộ và không có địa chỉ nào có thể chuyển tiếp. Mã trạng thái 404 được áp dụng rộng rãi khi máy chủ không muốn tiết lộ lý do tại sao yêu cầu bị từ chối hoặc khi không có bất kỳ phản hồi thích hợp nào có sẵn. |
| 405 |
Phương thức yêu cầu được chỉ định trong dòng yêu cầu không thể sử dụng cho tài nguyên ứng với yêu cầu. Phản hồi này phải trả về thông tin Allow để chỉ ra danh sách các phương thức yêu cầu mà tài nguyên hiện tại có thể chấp nhận. Do phương thức PUT, DELETE sẽ thực hiện thao tác ghi trên tài nguyên trên máy chủ, do đó hầu hết các máy chủ web không hỗ trợ hoặc không cho phép các phương thức yêu cầu này theo cấu hình mặc định, và phản hồi này sẽ trả về lỗi 405 cho các yêu cầu như vậy. |
| 406 |
Các thuộc tính nội dung của tài nguyên yêu cầu không thể đáp ứng điều kiện trong tiêu đề yêu cầu, do đó không thể tạo thực thể phản hồi. Trừ khi đây là một yêu cầu HEAD; thì phản hồi nên trả về một thực thể chứa danh sách các thuộc tính thực thể có thể cho phép người dùng hoặc trình duyệt chọn lựa chọn phù hợp nhất, cũng như danh sách địa chỉ. Định dạng thực thể được xác định bởi loại nội dung trong đầu vào tiêu đề Content-Type. Trình duyệt có thể tự nhiên đưa ra lựa chọn tốt nhất dựa trên định dạng và khả năng của chính nó. Tuy nhiên, quy định không định nghĩa tiêu chí nào cho việc đưa ra lựa chọn tự động này. |
| 407 |
Tương tự như phản hồi 401, chỉ là khách hàng phải chứng thực trên máy chủ proxy. Máy chủ proxy phải trả lại thông tin Proxy-Authenticate để yêu cầu xác thực. Khách hàng có thể trả lại tiêu đề Proxy-Authorization để xác thực. Xem RFC 2617. |
| 408 |
Thời gian yêu cầu đã vượt quá thời gian mà máy chủ đang chuẩn bị chờ đợi để hoàn tất gửi yêu cầu. Khách hàng có thể gửi lại yêu cầu này bất cứ lúc nào mà không cần thực hiện bất kỳ thay đổi nào. |
| 409 |
Yêu cầu không thể hoàn tất vì có xung đột với trạng thái hiện tại của tài nguyên được yêu cầu. Mã này chỉ được phép sử dụng trong các trường hợp như vậy: người dùng được cho là có khả năng giải quyết xung đột và sẽ gửi một yêu cầu mới. Phản hồi này nên bao gồm đủ thông tin để người dùng tìm ra nguồn gốc của xung đột. Xung đột thường xảy ra trong quá trình xử lý yêu cầu PUT. Ví dụ, trong một môi trường kiểm tra phiên bản, tin tức về việc gửi yêu cầu PUT sửa đổi tài nguyên cụ thể có thông tin phiên bản đính kèm tương ứng với một yêu cầu trước đó (bên thứ ba) bị xung đột, lúc này máy chủ nên trả về một lỗi 409 để thông báo cho người dùng rằng yêu cầu không thể hoàn tất. Thực thể phản hồi có thể có sự so sánh giữa hai phiên bản xung đột để giúp người dùng gửi lại phiên bản mới sau khi đã hợp nhất. |
| 410 |
Tài nguyên yêu cầu hiện không còn khả dụng trên máy chủ, và không có địa chỉ chuyển tiếp nào đã biết. Tình huống này nên được coi là vĩnh viễn. Nếu có thể, khách hàng có chức năng chỉnh sửa liên kết cũng nên xóa tất cả các tham chiếu đến địa chỉ đã nhận được sau khi được sự đồng ý người dùng. Nếu máy chủ không biết hoặc không chắc chắn về tình hình này có phải là vĩnh viễn hay không, thì nên sử dụng mã trạng thái 404. Trừ khi có chỉ định bổ sung, thì phản hồi này có thể được lưu trữ. Mục đích của phản hồi 410 chủ yếu là giúp quản trị viên trang web duy trì trang web, thông báo cho người dùng rằng tài nguyên này không còn khả dụng và chủ sở hữu máy chủ muốn tất cả các kết nối từ xa đến tài nguyên đó cũng bị xóa. Sự kiện này thường xảy ra đối với dịch vụ có thời hạn, dịch vụ gia tăng. Phản hồi 410 cũng được sử dụng để thông báo cho khách hàng rằng, trên trang máy chủ hiện tại, tài nguyên vốn thuộc về một cá nhân nào đó đã không còn khả dụng. Dĩ nhiên, việc có cần đánh dấu tất cả các tài nguyên không còn khả dụng như '410 Gone' và tận dụng vị trí này cho bao lâu hoàn toàn phụ thuộc vào chủ sở hữu máy chủ. |
| 411 |
Máy chủ từ chối nhận yêu cầu mà không có tiêu đề Content-Length đã xác định. Sau khi thêm tiêu đề Content-Length có hiệu lực chỉ ra chiều dài của nội dung tin nhắn yêu cầu, khách hàng có thể gửi lại yêu cầu này. |
| 412 |
Máy chủ không thể đáp ứng một hoặc nhiều điều kiện tiên quyết được đưa ra trong các trường tiêu đề yêu cầu. Mã trạng thái này cho phép khách hàng đặt điều kiện tiên quyết trong thông tin siêu của yêu cầu (dữ liệu trong các trường tiêu đề yêu cầu) để tránh việc phương thức yêu cầu được áp dụng cho nội dung không mong muốn mà họ hy vọng. |
| 413 |
Máy chủ từ chối xử lý yêu cầu hiện tại vì kích thước dữ liệu thực thể được gửi đi vượt quá giới hạn mà máy chủ sẵn sàng hoặc có khả năng xử lý. Trong tình huống này, máy chủ có thể đóng kết nối để ngăn khách hàng tiếp tục gửi yêu cầu này. Nếu tình huống này là tạm thời, máy chủ nên trả về một tiêu đề Retry-After trong phản hồi, thông báo cho khách hàng biết có thể thử lại sau bao lâu. |
| 414 |
Chiều dài của URI yêu cầu dài hơn chiều dài mà máy chủ có thể phân tích, do đó máy chủ từ chối phục vụ yêu cầu này. Tình huống này khá hiếm, có thể xảy ra các tình huống thông thường như: Lỗi chuyển nhiên trong biểu mẫu mà đáng lý phải sử dụng phương thức POST đã biến thành phương thức GET, gây ra chuỗi truy vấn quá dài. URI chuyển tiếp "hố đen", tức là mỗi lần chuyển tiếp sẽ lấy URI cũ làm phần của URI mới, gây ra URI bị quá dài sau nhiều lần chuyển tiếp. Khách hàng đang cố gắng tấn công máy chủ bằng cách tận dụng một số lỗ hổng bảo mật tồn tại trong một số máy chủ. Những máy chủ không gặp phải những lỗ hổng này, nên trả về mã trạng thái 414. |
| 415 |
Nội dung thực thể được gửi trong yêu cầu không phải là định dạng được hỗ trợ cho phương thức hiện tại và tài nguyên được yêu cầu. Do đó, yêu cầu bị từ chối. |
| 416 |
Nếu yêu cầu chứa tiêu đề Range, và bất kỳ miền nào trong Range được chỉ định không khớp với miền hiện có của tài nguyên, và nếu không có tiêu đề If-Range được xác định trong yêu cầu, thì máy chủ nên trả về mã trạng thái 416. Nếu Range sử dụng miền byte, thì tình huống này đề cập đến vị trí byte đầu tiên của miền dữ liệu được chỉ định trong yêu cầu đều vượt quá chiều dài hiện có của tài nguyên. Máy chủ cũng nên bao gồm một tiêu đề Content-Range để chỉ rõ chiều dài hiện có của tài nguyên khi trả về mã trạng thái 416. Phản hồi này cũng bị cấm sử dụng multipart/byteranges dưới dạng Content-Type của nó. |
| 417 |
Nội dung mà máy chủ giả định trong yêu cầu tiêu đề Expect không thể được đáp ứng, hoặc máy chủ là một máy chủ proxy có bằng chứng rõ ràng chứng tỏ rằng sự nội dung của Expect không thể được đáp ứng tại nút tiếp theo trong lộ trình hiện tại. |
| 421 |
Số liệu kết nối từ địa chỉ IP của khách hàng hiện tại tới máy chủ vượt quá số lượng tối đa mà máy chủ cho phép. Thường thì địa chỉ IP ở đây đề cập đến địa chỉ của khách hàng (ví dụ do gateway hoặc địa chỉ máy chủ proxy của người dùng hiện thấy từ máy chủ). Trong tình huống này, số lượng kết nối được tính có thể liên quan đến hơn một người dùng cuối. |
| 422 |
Số liệu kết nối từ địa chỉ IP của khách hàng hiện tại tới máy chủ vượt quá số lượng tối đa mà máy chủ cho phép. Thường thì địa chỉ IP ở đây đề cập đến địa chỉ của khách hàng (ví dụ do gateway hoặc địa chỉ máy chủ proxy của người dùng hiện thấy từ máy chủ). Trong tình huống này, số lượng kết nối được tính có thể liên quan đến hơn một người dùng cuối. |
| 422 |
Mã yêu cầu là chính xác, nhưng không thể phản hồi do có lỗi ngữ nghĩa. (RFC 4918 WebDAV) 423 Locked tài nguyên hiện tại đã bị khóa. (RFC 4918 WebDAV) |
| 424 |
Yêu cầu hiện tại đã thất bại do lỗi xảy ra từ một yêu cầu trước đó, ví dụ PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Được định nghĩa trong dự thảo Bộ sưu tập nâng cao WebDav nhưng không xuất hiện trong "Giao thức tập hợp WebDAV" (RFC 3658). |
| 426 |
Khách hàng nên chuyển đổi sang TLS/1.0. (RFC 2817) |
| 449 |
Được mở rộng bởi Microsoft, có nghĩa là yêu cầu nên được thử lại sau khi thực hiện các thao tác thích hợp. |
| 500 |
Máy chủ gặp một tình huống không mong đợi, dẫn đến việc không thể hoàn thành việc xử lý yêu cầu. Nói chung, vấn đề này thường xảy ra khi có lỗi trong mã chương trình của máy chủ. |
| 501 |
Máy chủ không hỗ trợ một số tính năng cần thiết cho yêu cầu hiện tại. Khi máy chủ không thể nhận dạng phương thức yêu cầu và không thể hỗ trợ yêu cầu cho bất kỳ tài nguyên nào. |
| 502 |
Máy chủ hoạt động như một gateway hoặc proxy đã nhận phản hồi không hợp lệ khi cố gắng thực hiện yêu cầu từ máy chủ upstream. |
| 503 |
Máy chủ hiện không thể xử lý yêu cầu do bảo trì tạm thời hoặc quá tải. Tình huống này là tạm thời và sẽ phục hồi sau vài khoảnh khắc. Nếu thời gian trì hoãn có thể dự đoán, phản hồi có thể bao gồm một tiêu đề Retry-After để thông báo thời gian trì hoãn đó. Nếu không có thông tin Retry-After nào được cung cấp, khách hàng nên xử lý nó giống như mã phản hồi 500. Lưu ý: sự tồn tại của mã trạng thái 503 không có nghĩa là máy chủ phải sử dụng nó khi bị quá tải. Một số máy chủ chỉ đơn giản là muốn từ chối kết nối khách hàng. |
| 504 |
Máy chủ hoạt động như một gateway hoặc proxy đã không nhận kịp thời phản hồi từ máy chủ upstream (uri máy chủ được xác định, ví dụ HTTP, FTP, LDAP) hoặc máy chủ phụ trợ (ví dụ DNS) khi cố gắng thực hiện yêu cầu. Lưu ý: một số máy chủ proxy có thể trả về lỗi 400 hoặc 500 khi thời gian tìm DNS đã hết hạn. |
| 505 |
Máy chủ không hỗ trợ hoặc từ chối sử dụng phiên bản HTTP được sử dụng trong yêu cầu. Điều này ngụ ý rằng máy chủ không thể hoặc không muốn sử dụng phiên bản giống như của khách hàng. Phản hồi nên bao gồm một thực thể mô tả lý do tại sao phiên bản không được hỗ trợ và máy chủ hỗ trợ các giao thức nào. |
| 506 |
Được mở rộng từ "Giao thức làm nội dung trong suốt" (RFC 2295), có nghĩa là máy chủ có lỗi cấu hình nội bộ: tài nguyên được yêu cầu để thực hiện các biến đàm phán đã được định cấu hình để sử dụng chính nó trong đàm phán nội dung trong suốt, do đó không phù hợp với mục đích trong một quá trình đàm phán. |
| 507 |
Máy chủ không thể lưu trữ nội dung cần thiết để hoàn tất yêu cầu. Tình trạng này được coi là tạm thời. WebDAV (RFC 4918) |
| 509 |
Máy chủ đã đạt tới giới hạn băng thông. Đây không phải là một mã trạng thái chính thức, nhưng vẫn được sử dụng rộng rãi. |
| 510 |
Phương thức để lấy nguồn tài nguyên không được đáp ứng. (RFC 2774) |