Enum hyper::status::StatusClass
[−]
[src]
pub enum StatusClass {
Informational,
Success,
Redirection,
ClientError,
ServerError,
NoClass,
}The class of an HTTP status-code.
RFC 7231, section 6 (Response Status Codes):
The first digit of the status-code defines the class of response. The last two digits do not have any categorization role.
And:
HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.
This can be used in cases where a status code’s meaning is unknown, also, to get the appropriate category of status.
Variants
Informational | 1xx (Informational): The request was received, continuing process |
Success | 2xx (Success): The request was successfully received, understood, and accepted |
Redirection | 3xx (Redirection): Further action needs to be taken in order to complete the request |
ClientError | 4xx (Client Error): The request contains bad syntax or cannot be fulfilled |
ServerError | 5xx (Server Error): The server failed to fulfill an apparently valid request |
NoClass | A status code lower than 100 or higher than 599. These codes do no belong to any class. |
Methods
impl StatusClass
fn default_code(&self) -> StatusCode
Get the default status code for the class.
This produces the x00 status code; thus, for ClientError (4xx), for
example, this will produce BadRequest (400):
assert_eq!(ClientError.default_code(), BadRequest);
The use for this is outlined in RFC 7231, section 6 (Response Status Codes):
HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.
This is demonstrated thusly:
// Suppose we have received this status code. // You will never directly create an unregistered status code. let status = Unregistered(471); // Uh oh! Don’t know what to do with it. // Let’s fall back to the default: let status = status.class().default_code(); // And look! That is 400 Bad Request. assert_eq!(status, BadRequest); // So now let’s treat it as that.
All status codes that do not map to an existing status class are matched
by a NoClass, variant that resolves to 200 (Ok) as default code.
This is a common handling for unknown status codes in major browsers.