| Mã trạng thái HTTP | Ý nghĩa mã trạng thái |
|---|
| 100 | Mặt khách 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 mặt khách rằng một số yêu cầu của nó đã được máy chủ nhận và không bị từ chối. Mặt khách nên tiếp tục gửi phần còn lại của yêu cầu, hoặc bỏ qua phản hồi nếu yêu cầu đã hoàn thành. Máy chủ phải gửi phản hồi cuối cùng cho mặt khách sau khi yêu cầu hoàn thành. |
| 101 | Máy chủ đã hiểu yêu cầu của khách và sẽ thông báo cho phần khách thông qua tiêu đề Upgrade để sử dụng giao thức khác để hoàn thành yêu cầu. Sau khi gửi dòng trống cuối cùng trong phản hồi, máy chủ sẽ chuyển sang các giao thức được định nghĩa trong tiêu đề Upgrade. Các biện pháp tương tự chỉ nên được thực hiện khi việc chuyển đổi sang giao thức mới có lợi hơn. Ví dụ, việc chuyển đổi sang phiên bản HTTP mới có lợi hơn so với phiên bản cũ, hoặc chuyển đổi sang giao thức thực}}-thời gian và giao thức đồng bộ để cung cấp tài nguyên tận dụng các tính năng này. |
| 102 | Mã trạng thái mở rộng bởi WebDAV (RFC 2518) chỉ ra rằng quá trình xử lý sẽ tiếp tục. |
| 200. | Yêu cầu đã thành công, và các tiêu đề phản hồi hoặc phần dữ liệu mong muốn được trả về cùng với phản hồi. |
| 201 | Yêu cầu đã được hoàn thành, và một tài nguyên mới đã được tạo dựa trên yêu cầu của yêu cầu, và URI của nó đã được trả về với tiêu đề Location. Nếu tài nguyên yêu cầu không thể được tạo ra kịp thời,'202 Đã chấp nhận' nên được trả về. |
| 202 | Máy chủ đã chấp nhận yêu cầu, nhưng nó vẫn chưa xử lý nó. Đều như có thể bị từ chối, yêu cầu có thể hoặc không được thực hiện cuối cùng. Trong trường hợp các hoạt động đồng bộ, không có cách nào tiện lợi hơn để làm điều này hơn là gửi mã trạng thái này. Mục đích của việc trả về 202 mã trạng thái phản hồi là để cho máy chủ chấp nhận yêu cầu từ các quá trình khác (như lô-hoạt động cơ bản được thực hiện chỉ một lần mỗi ngày) mà không cần giữ cho phần khách nối kết với máy chủ cho đến khi hoạt động lô hoàn thành. Đối với việc chấp nhận yêu cầu xử lý và trả về 202 mã trạng thái, thực thể trả về nên bao gồm một số thông tin chỉ ra trạng thái hiện tại của quá trình, cũng như một chỉ mục đến bộ giám sát hoặc dự đoán trạng thái quá trình, để người dùng có thể ước tính xem hoạt động có hoàn thành hay không. |
| 203 | Máy chủ đã xử lý thành công yêu cầu, nhưng thông tin meta tiêu đề thực thể trả về không phải là một tập hợp xác định hợp lệ trên máy chủ nguồn, mà là địa phương hoặc thứ-bản sao. Thông tin hiện tại có thể là một phần hoặc siêu tập của phiên bản gốc. Ví dụ, metadata chứa tài nguyên có thể làm máy chủ nguồn biết meta siêu. Sử dụng mã trạng thái này không bắt buộc và chỉ phù hợp nếu phản hồi trả về 200 OK mà không có mã trạng thái này. |
| 204 | Máy chủ đã xử lý thành công yêu cầu, nhưng không cần phải trả về bất kỳ nội dung vật lý nào, và mong muốn trả về thông tin meta đã cập nhật. Phản hồi có thể dưới dạng tiêu đề thực thể, trả về thông tin meta mới hoặc đã cập nhật. Nếu thông tin tiêu đề này tồn tại, nó nên tương ứng với biến được yêu cầu. Nếu bên khách là trình duyệt, thì trình duyệt người dùng nên giữ trang đã gửi yêu cầu mà không có bất kỳ thay đổi nào đối với视图 tài liệu, ngay cả khi thông tin meta mới hoặc đã cập nhật nên được áp dụng cho tài liệu trong view hoạt động của trình duyệt người dùng. Do đó 204 phản hồi bị cấm bao gồm bất kỳ nội dung thông báo nào, nó luôn kết thúc với dòng trống đầu tiên sau tiêu đề. |
| 205 | Máy chủ đã xử lý thành công yêu cầu và không trả về gì. Nhưng không giống như 204 Phản hồi, phản hồi trả về mã trạng thái này yêu cầu người yêu cầu phải đặt lại视图 tài liệu. Phản hồi này chủ yếu được sử dụng để đặt lại biểu mẫu ngay sau khi chấp nhận đầu vào của người dùng để người dùng có thể dễ dàng bắt đầu đầu vào khác. Như 204 phản hồi, thì phản hồi này cũng bị cấm bao gồm bất kỳ phần thân thông điệp nào và kết thúc với dòng trống đầu tiên sau tiêu đề. |
| 206 | Máy chủ đã xử lý thành công phần của yêu cầu GET. Các công cụ tải xuống HTTP như FlashGet hoặc Xunlei sử dụng loại phản hồi này để thực hiện việc tiếp tục tải xuống từ điểm ngắt hoặc để chia nhỏ một tài liệu lớn thành nhiều đoạn tải xuống đồng thời. Yêu cầu phải chứa tiêu đề Range để chỉ ra khoảng nội dung mà client muốn, và có thể bao gồm If-tiêu đề Range như một điều kiện yêu cầu. Phản hồi phải chứa các tiêu đề sau: Content-Range để chỉ ra khoảng nội dung được trả về trong phản hồi; nếu nó là nhiều-tải xuống đoạn với Content-Loại đa phần/byteranges, mỗi đoạn đa phần nên chứa một Content-tiêu đề Range để chỉ ra khoảng nội dung của đoạn này. 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ế trong khoảng nội dung mà nó trả về. Ngày ETag và/hoặc Content-Location, nếu yêu cầu này nên trả về một 2phản hồi 00. Expires, Cache-Kiểm soát, và/hoặc Vary, nếu giá trị của nó có thể khác với giá trị tương ứng với các phản hồi khác đối với cùng một biến trước đó. Nếu yêu cầu phản hồi này sử dụng If-tiêu đề Range mạnh cho việc xác thực cache, thì phản hồi này không nên bao gồm các tiêu đề thực thể khác; nếu yêu cầu phản hồi này sử dụng If-tiêu đề Range yếu cho việc xác thực cache, thì phản hồi này không nên bao gồm các tiêu đề thực thể 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ập nhật. Ngược lại, phản hồi này nên chứa tất cả các trường tiêu đề thực thể mà nên được trả về trong một 2phản hồi 00. Nếu ETag hoặc Last-tiêu đề Modified không khớp chính xác, bộ nhớ cache ở phía client nên cấm kết hợp nội dung được trả về trong phản hồi 206 nội dung đã được lưu trữ trước đó. Bất kỳ bộ nhớ cache nào không hỗ trợ Range và các-Tiêu đề Range bị cấm lưu trữ nội dung được trả về bởi phản hồi của 206 phản hồi. |
| 207 | Mã trạng thái mở rộng bởi WebDAV (RFC 2518) biểu thị rằng phần thân của thông điệp tiếp theo sẽ là một thông điệp XML, và có thể chứa một loạt các mã phản hồi độc lập dựa trên số lượng sub trước đó-từ xa. |
| 300 | Tài nguyên yêu cầu có một loạt các lựa chọn phản hồi, mỗi lựa chọn có địa chỉ cụ thể và yêu cầu trình duyệt-thiết lập. Người dùng hoặc trình duyệt có thể chọn địa chỉ ưa thích cho việc chuyển hướng. Trừ khi là yêu cầu HEAD, phản hồi nên bao gồm một phần thực thể với danh sách các thuộc tính tài nguyên và địa chỉ từ đó 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 của phần thực thể này được xác định bởi định dạng được định nghĩa bởi Content-Loại. Trình duyệt có thể tự động chọn lựa chọn phù hợp nhất dựa trên định dạng phản hồi và khả năng của trình duyệt. Tất nhiên, thông tin đàm phán dẫn động do RFC 2616 chuẩn không quy định cách chọn tự động như thế nào. Nếu máy chủ đã có một lựa chọn phản hồi ưa thích, URI của phản hồi nên được quy định trong Location; trình duyệt có thể sử dụng giá trị Location này như địa chỉ cho việc chuyển hướng tự động. Ngoài ra, mặc dù không có quy định khác, phản hồi cũng có thể được lưu trữ trong bộ nhớ cache. |
| 301 | Tài nguyên yêu cầu đã được di chuyển vĩnh viễn đến một địa điểm mới, và bất kỳ tham chiếu tương lai nào đến tài nguyên này nên sử dụng một trong số các URI được trả về bởi phản hồi này. Nếu có thể, phần client có khả năng chỉnh sửa liên kết nên tự động thay đổi địa chỉ yêu cầu thành địa chỉ được trả về từ máy chủ. Mặc dù không có quy định khác, phản hồi này cũng có thể được lưu trữ trong bộ nhớ cache. URI vĩnh viễn mới nên được trả về trong trường Location của phản hồi. Trừ khi là yêu cầu HEAD, phần thực thể của phản hồi nên chứa một liên kết đến URI mới và một mô tả ngắn gọn. Nếu không phải là yêu cầu GET hoặc HEAD, trình duyệt bị 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 của yêu cầu có thể thay đổi. Lưu ý: Đối với một số trình duyệt sử dụng HTTP/1.0 giao thức, khi họ gửi yêu cầu POST và nhận được 301 phản hồi, yêu cầu chuyển hướng tiếp theo sẽ là GET. |
| 302 | Tài nguyên được yêu cầu bây giờ đang phản hồi tạm thời cho yêu cầu từ URI khác. Do vậy, bên client nên tiếp tục gửi các yêu cầu tương lai đến địa chỉ gốc. Phản hồi này chỉ có thể được lưu trữ trong bộ nhớ cache nếu được chỉ định trong Cache-Điều khiển hoặc Expires. URI tạm thời mới nên được trả về trong trường Location của phản hồi. Trừ khi này là yêu cầu HEAD, phần tử phản hồi nên chứa một liên kết siêu текст đến URI mới và một mô tả ngắn gọn. Nếu này không phải là yêu cầu GET hoặc HEAD, trình duyệt cấm chuyển hướng tự động trừ khi được xác nhận bởi người dùng, vì điều kiện của yêu cầu có thể thay đổi do kết quả. Lưu ý: Mặc dù RFC 1945 và RFC 2068 định nghĩa không cho phép bên client thay đổi phương pháp yêu cầu khi chuyển hướng, nhiều trình duyệt hiện có coi 302 phản hồi như một 303 phản hồi và sử dụng GET để truy cập URI được chỉ định trong Location, bỏ qua phương pháp yêu cầu gốc. Mã trạng thái 303 và 307 được thêm để làm rõ điều mà máy chủ mong đợi từ bên client. |
| 303 | Phản hồi cho yêu cầu hiện tại có thể tìm thấy trên URI khác, và bên client nên yêu cầu truy cập vào tài nguyên đó. Phương pháp này tồn tại chủ yếu để cho phép script-Kết quả yêu cầu POST được kích hoạt để được chuyển hướng đến tài nguyên mới. URI mới này không phải là tham chiếu thay thế cho tài nguyên gốc. Ngoài ra, 303 phản hồi bị cấm lưu trữ. Tất nhiên, một 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 trường Location của phản hồi. Trừ khi này là yêu cầu HEAD, thực thể phản hồi nên chứa một liên kết hyperlinke đến URI mới và một mô tả ngắn gọn. Lưu ý: Nhiều trình duyệt trước HTTP/1.1 không hiểu 303 trạng thái chính xác. Nếu bạn cần xem xét tương tác với các trình duyệt này, các 302 mã trạng thái nên đủ, vì hầu hết các trình duyệt xử lý 302 phản hồi một cách chính xác theo cách mà quy định trên yêu cầu máy khách xử lý 303 phản hồi. |
| 304 | Nếu máy khách gửi yêu cầu GET điều kiện và yêu cầu đã được phép, và nội dung tài liệu không thay đổi (từ lần truy cập cuối cùng hoặc theo điều kiện của yêu cầu), máy chủ nên trả về mã trạng thái này. 304 phản hồi bị cấm bao gồm phần thân tin nhắn, vì vậy luôn kết thúc bằng một dòng trống đầu tiên sau đầu đề. Phản hồi phải chứa thông tin đầ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ồ cũng tuân thủ các quy tắc này, thì máy chủ proxy và máy khách có thể tự mình thêm trường Date vào đầu đề phản hồi đã nhận (theo như được quy định trong RFC 2068), và cơ chế lưu trữ sẽ hoạt động tốt. ETag và/hoặc Content-Location, nếu yêu cầu này nên trả về một 2phản hồi 00. Expires, Cache-Kiểm soát, và/hoặc Vary, nếu giá trị của nó có thể khác với giá trị tương ứng với các phản hồi khác đối với cùng một biến trước đó.
Nếu yêu cầu phản hồi này sử dụng xác thực tệp lưu trữ mạnh, thì phản hồi này không nên bao gồm các đầu đề thực thể khác; ngược lại (ví dụ, yêu cầu GET điều kiện sử dụng xác thực tệp lưu trữ yếu), phản hồi này bị cấm bao gồm các đầu đề thực thể 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 đầu đề thực thể đã cập nhật. Nếu một 304 phản hồi cho thấy thực thể không được lưu trữ trong bộ nhớ cache hiện tại, hệ thống lưu trữ bộ nhớ cache phải bỏ qua phản hồi và gửi lại các yêu cầu mà không có giới hạn.
Nếu một 304 phản hồi được nhận để cập nhật một mục lưu trữ trong bộ nhớ cache, hệ thống lưu trữ bộ nhớ cache phải cập nhật toàn bộ mục để phản ánh giá trị của tất cả các trường đã được cập nhật trong phản hồi. |
| 305 | Tài nguyên yêu cầu phải được truy cập thông qua proxy được chỉ định. Thông tin URI của proxy được chỉ định được cung cấp trong trường Location. Người nhận cần gửi lại yêu cầu riêng biệt để truy cập tài nguyên tương ứng thông qua proxy này. Chỉ có máy chủ nguồn mới có thể thiết lập một 305 phản hồi. Lưu ý: Không có sự xác định rõ ràng 305 phản hồi trong RFC 2068 để chuyển hướng một yêu cầu duy nhất, và nó chỉ có thể được thiết lập bởi máy chủ nguồn. Bỏ qua các giới hạn này có thể dẫn đến hậu quả an ninh nghiêm trọng. |
| 306 | Trong phiên bản mới nhất của quy định, 306 mã trạng thái không còn được sử dụng. |
| 307 | Tài nguyên yêu cầu hiện đang phản hồi tạm thời cho yêu cầu từ URI khác. Do các chuyển hướng này là tạm thời, phía khách hàng nên tiếp tục gửi các yêu cầu tương lai đến địa chỉ gốc. Phản hồi này chỉ có thể được lưu trữ trong bộ nhớ cache nếu được chỉ định trong Cache-hoặc Expires. URI tạm thời mới nên được trả về trong trường Location của phản hồi. Trừ khi đó là yêu cầu HEAD, thực thể phản hồi nên chứa một liên kết siêu tekst chỉ đến URI mới và một mô tả ngắn gọn. Do một số trình duyệt không nhận ra 307 phản hồi, thông tin trên cần được thêm vào để người dùng có thể hiểu và yêu cầu truy cập vào URI mới.
Nếu không phải là yêu cầu GET hoặc HEAD, trình duyệt sẽ không cho phép tự động chuyển hướng trừ khi người dùng xác nhận, vì điều kiện của yêu cầu có thể thay đổi. |
| 400 | 1. Cấu nghĩa không đúng, yêu cầu hiện tại không thể được hiểu bởi máy chủ. Trừ khi được thay đổi, bên khách không nên gửi lại yêu cầu nhiều lần. 2. Các tham số yêu cầu không đúng. |
| 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 phải chứa một WWW-đầu đề xác thực cho tài nguyên yêu cầu để yêu cầu người dùng cung cấp thông tin. Bên khách có thể gửi lại yêu cầu với thông tin đầu đề ủy quyền phù hợp. Nếu yêu cầu hiện tại đã chứa chứng chỉ ủy quyền, then the 401 phản hồi biểu thị rằng máy chủ đã từ chối những chứng chỉ đó. Nếu the 401 phản hồi chứa cùng câu hỏi xác thực như phản hồi trước đó, và trình duyệt đã thử xác thực ít nhất một lần, thì trình duyệt nên hiển thị cho người dùng 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 để trống cho các yêu cầu tương lai có thể. |
| 403 | Máy chủ đã hiểu yêu cầu, nhưng từ chối thực hiện nó. Khác với một 401 phản hồi, xác thực không giúp ích, và yêu cầu không nên được lặp lại. Nếu này không phải là yêu cầu HEAD, và máy chủ muốn có thể giải thích lý do tại sao yêu cầu không thể thực hiện được, thì lý do từ chối nên được mô tả trong thực thể. Tất nhiên, máy chủ cũng có thể trả về một 404 phản hồi nếu nó không muốn người dùng nhận bất kỳ thông tin nào. |
| 404 | Yêu cầu bị từ chối, 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 để thông báo cho người dùng rằng tình trạng này là tạm thời hay vĩnh viễn. Nếu máy chủ biết rõ tình hình, the 410 Mã trạng thái nên được sử dụng để thông báo cho tài nguyên cũ rằng nó không thể truy cập được vĩnh viễn do một cơ chế cấu hình nội bộ và không có địa chỉ để nhảy sang. The 404 Mã trạng thái được sử dụng rộng rãi khi máy chủ không muốn tiết lộ lý do yêu cầu bị từ chối hoặc không có phản hồi phù hợp nào có sẵn. |
| 405 | Phương pháp yêu cầu được chỉ định trong dòng yêu cầu không thể được sử dụng để yêu cầu tài nguyên tương ứng. Phản hồi phải trả về tiêu đề Allow chỉ ra danh sách các phương pháp yêu cầu có thể được tài nguyên hiện tại chấp nhận. Do phương pháp PUT và DELETE ghi dữ liệu vào tài nguyên trên máy chủ, hầu hết các máy chủ web không hỗ trợ hoặc không cho phép phương pháp yêu cầu trên theo mặc định và sẽ trả về một 405 lỗi cho các yêu cầu này. |
| 406 | Tính chất nội dung của tài nguyên được yêu cầu không phù hợp với điều kiện trong tiêu đề yêu cầu, vì vậy không thể tạo ra thực thể phản hồi. Trừ khi này là yêu cầu HEAD, phản hồi nên trả về một thực thể cho phép người dùng hoặc trình duyệt chọn tính chất thực thể phù hợp nhất và danh sách địa chỉ. Định dạng của thực thể được xác định bởi loại truyền thông được định nghĩa trong Content-Tiêu đề loại. Trình duyệt có thể chọn tốt nhất dựa trên định dạng và khả năng của mình. Tuy nhiên, quy định không định nghĩa bất kỳ tiêu chí nào để làm lựa chọn tự động như vậy. |
| 407 | Tương tự như 401 phản hồi, nhưng phía khách hàng phải xác thực trên máy chủ_proxy. Máy chủ_proxy phải trả về một Proxy-Xác thực cho xác thực. Phía khách hàng có thể trả về một Proxy-Tiêu đề xác thực. Xem RFC 2617. |
| 408 | Yêu cầu hết thời gian chờ. Phía khách hàng không hoàn thành việc gửi yêu cầu trong thời gian mà máy chủ sẵn sàng chờ. Phía khách hàng có thể gửi lại yêu cầu vào bất kỳ thời điểm nào mà không cần thay đổi. |
| 409 | Yêu cầu không thể hoàn thành do 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 nếu giả định người dùng có thể giải quyết xung đột và sẽ gửi lại yêu cầu mới. Phản hồi nên chứa đủ thông tin để người dùng phát hiện nguồn 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 phiên bản-môi trường đã kiểm tra, nếu thông tin phiên bản gắn vào PUT-yêu cầu chỉnh sửa đã gửi cho một tài nguyên cụ thể xung đột với một yêu cầu trước đó (thứ ba)-yêu cầu từ bên thứ ba) máy chủ nên trả về một 409 lỗi thông báo cho người dùng rằng yêu cầu không thể hoàn thành.
Tại thời điểm này, thực thể phản hồi có thể chứa sự so sánh sự khác biệt giữa hai phiên bản xung đột, để người dùng có thể gửi lại phiên bản hợp nhất. |
| 410 | Tài nguyên yêu cầu không còn khả dụng trên máy chủ và không có địa chỉ chuyển tiếp nào được biết. Điều kiện này nên được coi là vĩnh viễn. Nếu có thể, bên khách có khả năng chỉnh sửa liên kết nên xóa tất cả các tham chiếu đến địa chỉ này với sự cho phép của người dùng. Nếu máy chủ không biết hoặc không thể xác định liệu điều kiện này là vĩnh viễn hay không, thì một 404 mã trạng thái nên được sử dụng. Trừ khi được chỉ định khác, phản hồi này có thể được lưu cache. Mục đích của 410 phản hồi chủ yếu để giúp quản trị viên web duy trì trang web, thông báo cho người dùng rằng tài nguyên 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 này bị xóa.
Loại sự kiện này rất phổ biến trong thời gian-giới hạn, giá trị-dịch vụ đã thêm. Tương tự, 410 phản hồi được sử dụng để thông báo cho bên khách rằng tài nguyên ban đầu thuộc về cá nhân không còn khả dụng trên trang web hiện tại của máy chủ. Tất nhiên, điều này hoàn toàn phụ thuộc vào chủ sở hữu máy chủ có đánh dấu tất cả tài nguyên không còn khả dụng vĩnh viễn như' 410 Gone ', và thời gian giữ dấu này. |
| 411 | Máy chủ từ chối chấp nhận yêu cầu mà không xác định nội dung.-Tiêu đề độ dài.-Tiêu đề độ dài chỉ ra độ dài của phần thân yêu cầu, bên khách có thể gửi yêu cầu lại. |
| 412 | Máy chủ không đạt được một hoặc nhiều yêu cầu trước khi xác minh rằng chúng được cung cấp trong trường hợp tiêu đề của yêu cầu. Mã trạng thái này cho phép bên client đặt các yêu cầu trước trong metadata được yêu cầu (dữ liệu trường tiêu đề yêu cầu) khi lấy tài nguyên, do đó ngăn chặn phương pháp yêu cầu được áp dụng cho tài nguyên khác ngoài những gì nó muốn. |
| 413 | Máy chủ từ chối xử lý yêu cầu hiện tại vì yêu cầu gửi nhiều dữ liệu thực thể hơn máy chủ sẵn sàng hoặc có thể xử lý. Trong trường hợp này, máy chủ có thể đóng kết nối để ngăn bên client tiếp tục gửi yêu cầu. Nếu tình trạng này là tạm thời, máy chủ nên trả về một Retry-Sau tiêu đề phản hồi để thông báo cho bên client biết bao lâu họ có thể thử lại. |
| 414 | URI được yêu cầu dài hơn mức mà máy chủ có thể giải thích, vì vậy máy chủ từ chối phục vụ yêu cầu. Điều này rất hiếm, và các trường hợp phổ biến bao gồm: Một biểu mẫu gửi đi mà nên sử dụng phương pháp POST trở thành phương pháp GET, gây ra chuỗi truy vấn (Query String) quá dài. URI chuyển hướng "đ黑洞", chẳng hạn như mỗi chuyển hướng sử dụng URI cũ như một phần của URI mới, dẫn đến URI quá dài sau nhiều lần chuyển hướng. Client đang cố gắng tấn công máy chủ bằng các lỗ hổng bảo mật tồn tại trong một số máy chủ.
Loại máy chủ này sử dụng một-buffer chiều dài để đọc hoặc thao tác URI được yêu cầu. Khi các tham số sau GET vượt quá một giá trị nhất định, có thể xảy ra tràn buffer, dẫn đến việc thực thi mã ngẫu nhiên [1]. Các máy chủ không có các lỗ hổng như vậy nên trả về một 414 mã trạng thái. |
| 415 | Đối với phương pháp của yêu cầu hiện tại và tài nguyên được yêu cầu, thực thể được gửi trong yêu cầu không ở định dạng được máy chủ hỗ trợ, vì vậy yêu cầu bị từ chối. |
| 416 | Nếu yêu cầu chứa tiêu đề Range và bất kỳ khoảng dữ liệu nào được chỉ định trong Range không khớp với khoảng dữ liệu hiện có của tài nguyên hiện tại, và If-Tiêu đề Range không được định nghĩa trong yêu cầu, máy chủ nên trả về một 416 mã trạng thái. Nếu Range sử dụng byte range, thì tình huống này có nghĩa là vị trí byte đầu tiên của tất cả các khoảng dữ liệu được chỉ định bởi yêu cầu vượt quá độ dài của tài nguyên hiện tại. Máy chủ cũng nên bao gồm một Content-tiêu đề thể Range cùng với 416 mã trạng thái để chỉ ra độ dài của tài nguyên hiện tại. Phản hồi này cũng bị cấm sử dụng multipart/byteranges như nội dung của nó-Loại. |
| 417 | Nội dung mong đợi được chỉ định trong tiêu đề yêu cầu Expect không thể được máy chủ đáp ứng, hoặc máy chủ là máy chủ đại lý có bằng chứng rõ ràng rằng nội dung mong đợi không thể được đáp ứng ở bước tiếp theo của tuyến đường hiện tại. |
| 421 | Số lượng kết nối đến máy chủ từ địa chỉ Internet Protocol nơi bên khách hiện tại đang ở vượt quá mức tối đa được máy chủ cho phép. Thường thì địa chỉ Internet Protocol ở đây là địa chỉ bên khách nhìn từ máy chủ (chẳng hạn như địa chỉ cổng hoặc máy chủ đại lý của người dùng). Trong trường hợp này, số lượng kết nối có thể涉及到 nhiều hơn một người dùng cuối. |
| 422 | Số lượng kết nối đến máy chủ từ địa chỉ Internet Protocol nơi bên khách hiện tại đang ở vượt quá mức tối đa được máy chủ cho phép. Thường thì địa chỉ Internet Protocol ở đây là địa chỉ bên khách nhìn từ máy chủ (chẳng hạn như địa chỉ cổng hoặc máy chủ đại lý của người dùng). Trong trường hợp này, số lượng kết nối có thể涉及到 nhiều hơn một người dùng cuối. |
| 422 | Yêu cầu đã được định dạng đúng, nhưng không thể phản hồi do lỗi ngữ nghĩa. (RFC 4918 WebDAV) 423 Khóa Tài nguyên hiện tại đang bị khóa. (RFC 4918 WebDAV) |
| 424 | Yêu cầu hiện tại đã thất bại do lỗi trong yêu cầu trước, chẳng hạn như PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Định nghĩa trong dự thảo WebDav Advanced Collections, nhưng không trong giao thức WebDAV Sequential Set (RFC 3658). |
| 426 | Bên khách nên chuyển sang TLS/1.0. (RFC 2817) |
| 449 | Phát triển bởi Microsoft, yêu cầu nên được thử lại sau khi thực hiện hành động phù hợp. |
| 500 | Máy chủ gặp phải tình huống bất ngờ ngăn cản nó hoàn thành yêu cầu. Thường thì vấn đề này xảy ra khi mã của máy chủ gặp lỗi. |
| 501 | Máy chủ không hỗ trợ tính năng yêu cầu bởi yêu cầu hiện tại. Khi máy chủ không thể nhận ra phương pháp yêu cầu và không hỗ trợ yêu cầu của nó đối với bất kỳ tài nguyên nào. |
| 502 | Khi một máy chủ hoạt động như một cổng hoặc đại lý thử thực thi một yêu cầu, nó nhận được một phản hồi không hợp lệ từ máy chủ cấp trên. |
| 503 | Máy chủ hiện tại không thể xử lý yêu cầu do bảo trì tạm thời hoặc quá tải. Tình trạng này là tạm thời và sẽ được khôi phục sau một thời gian. Nếu thời gian chậm trễ có thể dự đoán, phản hồi có thể bao gồm một Retry-Sau tiêu đề để chỉ ra thời gian chậm trễ. Nếu thời gian chậm trễ có thể dự đoán, phản hồi có thể bao gồm một Retry-Sau khi không cung cấp thông tin, bên khách nên xử lý nó như thể nó là một 5phản hồi. Ghi chú: Sự có mặt của một 503 mã trạng thái không có nghĩa là máy chủ phải sử dụng nó trong trường hợp quá tải. Một số máy chủ đơn giản chỉ muốn từ chối kết nối của khách. |
| 504 | Khi một máy chủ hoạt động như một cổng hoặc đại lý cố gắng thực hiện một yêu cầu, nó không nhận được phản hồi từ máy chủ lên chảy (được xác định bởi URI, chẳng hạn như HTTP, FTP, LDAP) hoặc máy chủ thứ cấp (chẳng hạn như DNS) một cách kịp thời. Ghi chú: Một số máy chủ đại lý trả về 400 hoặc 5Lỗi 00 khi truy vấn DNS hết hạn |
| 505 | Máy chủ không hỗ trợ hoặc từ chối hỗ trợ phiên bản HTTP được sử dụng trong yêu cầu. Điều này có nghĩa là máy chủ không thể hoặc sẽ không sử dụng cùng phiên bản với bên khách. 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à các giao thức mà máy chủ hỗ trợ. |
| 506 | Phát triển bởi Giao thức Đàm phán Nội dung Rõ ràng (RFC 2295), điều này đại diện cho lỗi cấu hình nội bộ trên máy chủ: biến tham số đàm phán yêu cầu được cấu hình để sử dụng chính nó trong đàm phán nội dung rõ ràng, và do đó không phải là điểm tập trung hợp lý trong 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 thành 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 đến giới hạn băng thông. Điều này không phải là mã trạng thái chính thức, nhưng nó vẫn được sử dụng rộng rãi. |
| 510 | Các chính sách cần thiết để thu thập tài nguyên không được đáp ứng. (RFC 2774) |
