Enum hyper::status::StatusClass
[-]
[+]
[src]
pub enum StatusClass {
Informational,
Success,
Redirection,
ClientError,
ServerError,
}The class of an HTTP Status-Code.
RFC 2616, section 6.1.1 (Status Code and Reason Phrase):
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role.
...
HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.
This can be used in cases where a status code’s meaning is unknown, also, to get the appropriate category of status.
For HTTP/2.0, the 1xx Informational class is invalid.
Variants
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 2616, section 6.1.1 (Status Code and Reason Phrase):
HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.
This is demonstrated thusly (I’ll use 432 rather than 431 as 431 is now in use):
// Suppose we have received this status code. let status = Code432; // 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.