rwf2
/
Rocket
mirror of https://github.com/rwf2/Rocket.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Rocket/lib/src/catcher.rs

246 lines
9.2 KiB
Rust
Raw Normal View History

New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
use response;
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
use handler::ErrorHandler;
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
use codegen::StaticCatchInfo;
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
use error::Error;
use request::Request;
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
use std::fmt;
use term_painter::ToStyle;
use term_painter::Color::*;
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
/// An error catching route.
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
///
/// Catchers are routes that run when errors occur. They correspond directly
/// with the HTTP error status code they will be handling and are registered
/// with Rocket via the [Rocket::catch](/rocket/struct.Rocket.html#method.catch)
/// method. For example, to handle "404 not found" errors, a catcher for the
/// "404" status code is registered.
///
/// Because error handlers are only called when all routes are exhausted, they
/// should not fail nor forward. If an error catcher fails, the user will
/// receive no response. If an error catcher forwards, Rocket will respond with
/// an internal server error.
///
/// # Built-In Catchers
///
/// Rocket has many built-in, pre-registered default catchers. In particular,
/// Rocket has catchers for all of the following status codes: 400, 401, 402,
/// 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417,
/// 418, 421, 426, 428, 429, 431, 451, 500, 501, 503, and 510. As such, catchers
/// only need to be registered if an error needs to be handled in a custom
/// fashion.
///
/// # Code Generation
///
/// Catchers should rarely be used directly. Instead, they are typically
/// declared using the `error` decorator, as follows:
///
/// ```rust
/// #![feature(plugin)]
/// #![plugin(rocket_codegen)]
///
/// extern crate rocket;
///
/// use rocket::Request;
///
/// #[error(500)]
/// fn internal_error() -> &'static str {
/// "Whoops! Looks like we messed up."
/// }
///
/// #[error(400)]
/// fn not_found(req: &Request) -> String {
/// format!("I couldn't find '{}'. Try something else?", req.uri())
/// }
///
/// fn main() {
/// # if false { // We don't actually want to launch the server in an example.
/// rocket::ignite().catch(errors![internal_error, not_found]).launch()
/// # }
/// }
/// ```
///
/// A function decorated with `error` can take in 0, 1, or 2 parameters:
/// `Error`, `&Request`, or both, as desired.
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
pub struct Catcher {
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
/// The HTTP status code to match against.
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
pub code: u16,
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
handler: ErrorHandler,
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
is_default: bool,
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
}
impl Catcher {
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
/// Creates a catcher for the given status code using the given error
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
/// handler. This should only be used when routing manually.
///
/// # Examples
///
/// ```rust
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
/// use rocket::{Catcher, Request, Error};
/// use rocket::response::{Result, Responder};
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
///
Rework Request: add lifetime to future proof, remove unsafe.
2016-12-16 11:07:23 +00:00
/// fn handle_404<'r>(_: Error, req: &'r Request) -> Result<'r> {
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
/// format!("Couldn't find: {}", req.uri()).respond()
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
/// }
///
Rework Request: add lifetime to future proof, remove unsafe.
2016-12-16 11:07:23 +00:00
/// fn handle_500<'r>(_: Error, _: &'r Request) -> Result<'r> {
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
/// "Whoops, we messed up!".respond()
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
/// }
///
/// let not_found_catcher = Catcher::new(404, handle_404);
/// let internal_server_error_catcher = Catcher::new(500, handle_500);
/// ```
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
#[inline(always)]
Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
pub fn new(code: u16, handler: ErrorHandler) -> Catcher {
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
Catcher { code: code, handler: handler, is_default: false }
Working error handling! Not quite there yet though. A few important things needs to get this to be 'right': 1a. Have a way to return a response with a status code. 1b. Use that mechanism in the default catchers. 2. Automatically fill in that code from the #[error] handler. 3. Have a way for a responder to say if responding succeeded. 4. Try next highest ranking route if responding with one handler fails.
2016-04-06 20:50:02 +00:00
}
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
#[doc(hidden)]
#[inline(always)]
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
pub fn handle<'r>(&self, err: Error, req: &'r Request) -> response::Result<'r> {
(self.handler)(err, req)
Progress on errors. Started Todo example. The error function now takes in a "RoutingError" structure. The idea is that the structure includes all of the information necessary for a user to processor the error as they wish. This interface is very incomplete and may change. At a minimum, the error structure should include: 1) The request that failed. 2) Why the request failed. 3) The chain of attempted route matches, if any. 4) Something else?
2016-07-16 04:09:08 +00:00
}
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
#[inline(always)]
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
fn new_default(code: u16, handler: ErrorHandler) -> Catcher {
Catcher { code: code, handler: handler, is_default: true, }
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
}
Working error handling! Not quite there yet though. A few important things needs to get this to be 'right': 1a. Have a way to return a response with a status code. 1b. Use that mechanism in the default catchers. 2. Automatically fill in that code from the #[error] handler. 3. Have a way for a responder to say if responding succeeded. 4. Try next highest ranking route if responding with one handler fails.
2016-04-06 20:50:02 +00:00
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
#[doc(hidden)]
#[inline(always)]
Working error handling! Not quite there yet though. A few important things needs to get this to be 'right': 1a. Have a way to return a response with a status code. 1b. Use that mechanism in the default catchers. 2. Automatically fill in that code from the #[error] handler. 3. Have a way for a responder to say if responding succeeded. 4. Try next highest ranking route if responding with one handler fails.
2016-04-06 20:50:02 +00:00
pub fn is_default(&self) -> bool {
self.is_default
}
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
}
Document the Rocket type. Add expect method to Outcome. Add custom method to Rocket.
2016-11-04 13:35:04 +00:00
#[doc(hidden)]
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
impl<'a> From<&'a StaticCatchInfo> for Catcher {
fn from(info: &'a StaticCatchInfo) -> Catcher {
Catcher::new(info.code, info.handler)
}
}
impl fmt::Display for Catcher {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
Working error handling! Not quite there yet though. A few important things needs to get this to be 'right': 1a. Have a way to return a response with a status code. 1b. Use that mechanism in the default catchers. 2. Automatically fill in that code from the #[error] handler. 3. Have a way for a responder to say if responding succeeded. 4. Try next highest ranking route if responding with one handler fails.
2016-04-06 20:50:02 +00:00
write!(f, "{}", Blue.paint(&self.code))
Progress on error handling. Calling them 'catchers' for now. Added `error` decorator and `errors` macro. The current idea is that you can have "catchers" for all valid errors code (in range [400, 500). At the moment, catchers are just request handlers, and the decorator expected an empty function signature for the error handler. Obviously, this is pretty useless. Not sure on what the API should be here. But, progress. Oh, one more thing: who should handle forwarding a request to a catcher? Probably not the router. So, the main Rocket should?
2016-04-06 10:26:43 +00:00
}
}
Working error handling! Not quite there yet though. A few important things needs to get this to be 'right': 1a. Have a way to return a response with a status code. 1b. Use that mechanism in the default catchers. 2. Automatically fill in that code from the #[error] handler. 3. Have a way for a responder to say if responding succeeded. 4. Try next highest ranking route if responding with one handler fails.
2016-04-06 20:50:02 +00:00
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
macro_rules! error_page_template {
($code:expr, $name:expr, $description:expr) => (
concat!(r#"
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
<title>"#, $code, " ", $name, r#"</title>
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
</head>
<body align="center">
<div align="center">
Completely new raw API. Summary of changes: * Request no longer has a lifetime parameter. * Handler type now includes a `Data` parameter. * Response is now an enum that is either `Complete` or `Forward`. * Outcome enum is now one of: Success, Failure, Forward. * Outcome::Foward for Responses must include StatusCode. * Responders are now final: they cannot forward to requests. (!!) * Responsers may only forward to catchers. (!!) * Response no longer provides wrapping methods. * Route is now cloneable. This change is fundamental to enabling streaming requests.
2016-10-08 06:20:49 +00:00
<h1>"#, $code, ": ", $name, r#"</h1>
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
<p>"#, $description, r#"</p>
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
<hr />
<small>Rocket</small>
</div>
</body>
</html>
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
"#
)
)
}
Working error handling! Not quite there yet though. A few important things needs to get this to be 'right': 1a. Have a way to return a response with a status code. 1b. Use that mechanism in the default catchers. 2. Automatically fill in that code from the #[error] handler. 3. Have a way for a responder to say if responding succeeded. 4. Try next highest ranking route if responding with one handler fails.
2016-04-06 20:50:02 +00:00
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
macro_rules! default_errors {
($($code:expr, $name:expr, $description:expr, $fn_name:ident),+) => (
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
let mut map = HashMap::new();
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
$(
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
fn $fn_name<'r>(_: Error, _r: &'r Request) -> response::Result<'r> {
status::Custom(Status::from_code($code).unwrap(),
Rename `data` to `content` in `response`. Remove `DataOutcome`.
2016-10-25 11:03:50 +00:00
content::HTML(error_page_template!($code, $name, $description))
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
).respond()
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
}
map.insert($code, Catcher::new_default($code, $fn_name));
)+
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
map
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
)
}
pub mod defaults {
use super::Catcher;
use std::collections::HashMap;
use request::Request;
New HTTP types: ContentType, Status. Responder/Handler/ErrorHandler changed. This is a complete rework of `Responder`s and of the http backend in general. This gets Rocket one step closer to HTTP library independence, enabling many future features such as transparent async I/O, automatic HEAD request parsing, pre/post hooks, and more. Summary of changes: * `Responder::response` no longer takes in `FreshHyperResponse`. Instead, it returns a new `Response` type. * The new `Response` type now encapsulates a full HTTP response. As a result, `Responder`s now return it. * The `Handler` type now returns an `Outcome` directly. * The `ErrorHandler` returns a `Result`. It can no longer forward, which made no sense previously. * `Stream` accepts a chunked size parameter. * `StatusCode` removed in favor of new `Status` type. * `ContentType` significantly modified. * New, lightweight `Header` type that plays nicely with `Response`.
2016-12-15 08:47:31 +00:00
use response::{self, content, status, Responder};
use http::Status;
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
use error::Error;
pub fn get() -> HashMap<u16, Catcher> {
default_errors! {
400, "Bad Request", "The request could not be understood by the server due
to malformed syntax.", handle_400,
401, "Unauthorized", "The request requires user authentication.",
handle_401,
402, "Payment Required", "The request could not be processed due to lack of
payment.", handle_402,
Further document the Catcher type. Register a catcher in the manual example.
2016-11-05 18:31:50 +00:00
403, "Forbidden", "The request was forbidden by the server.
Check authentication.", handle_403,
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
404, "Not Found", "The requested resource could not be found.", handle_404,
405, "Method Not Allowed", "The request method is not supported for the
requested resource.", handle_405,
406, "Not Acceptable", "The requested resource is capable of generating
only content not acceptable according to the Accept headers sent in the
request.", handle_406,
407, "Proxy Authentication Required", "Authentication with the proxy is
required.", handle_407,
408, "Request Timeout", "The server timed out waiting for the
request.", handle_408,
409, "Conflict", "The request could not be processed because of a conflict
in the request.", handle_409,
410, "Gone", "The resource requested is no longer available and will not be
available again.", handle_410,
411, "Length Required", "The request did not specify the length of its
content, which is required by the requested resource.", handle_411,
412, "Precondition Failed", "The server does not meet one of the
preconditions specified in the request.", handle_412,
413, "Payload Too Large", "The request is larger than the server is
willing or able to process.", handle_413,
414, "URI Too Long", "The URI provided was too long for the server to
process.", handle_414,
415, "Unsupported Media Type", "The request entity has a media type which
the server or resource does not support.", handle_415,
416, "Range Not Satisfiable", "The portion of the requested file cannot be
supplied by the server.", handle_416,
417, "Expectation Failed", "The server cannot meet the requirements of the
Expect request-header field.", handle_417,
418, "I'm a teapot", "I was requested to brew coffee, and I am a
teapot.", handle_418,
421, "Misdirected Request", "The server cannot produce a response for this
request.", handle_421,
426, "Upgrade Required", "Switching to the protocol in the Upgrade header
field is required.", handle_426,
428, "Precondition Required", "The server requires the request to be
conditional.", handle_428,
429, "Too Many Requests", "Too many requests have been received
recently.", handle_429,
431, "Request Header Fields Too Large", "The server is unwilling to process
the request because either an individual header field, or all
the header fields collectively, are too large.", handle_431,
451, "Unavailable For Legal Reasons", "The requested resource is
unavailable due to a legal demand to deny access to this
resource.", handle_451,
500, "Internal Server Error", "The server encountered an internal error
while processing this request.", handle_500,
501, "Not Implemented", "The server either does not recognize the request
method, or it lacks the ability to fulfill the request.", handle_501,
503, "Service Unavailable", "The server is currently unavailable.",
handle_503,
510, "Not Extended", "Further extensions to the request are required for
the server to fulfill it.", handle_510
}
Progress on errors. Started Todo example. The error function now takes in a "RoutingError" structure. The idea is that the structure includes all of the information necessary for a user to processor the error as they wish. This interface is very incomplete and may change. At a minimum, the error structure should include: 1) The request that failed. 2) Why the request failed. 3) The chain of attempted route matches, if any. 4) Something else?
2016-07-16 04:09:08 +00:00
}
}
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00