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

170 lines
6.6 KiB
Rust
Raw Normal View History

Major overhual: Request, ErrorHandler, ContentType.
2016-08-26 08:55:11 +00:00
use handler::ErrorHandler;
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
use response::Response;
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::*;
pub struct Catcher {
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
}
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
// TODO: Should `Catcher` be an interface? Should there be an `ErrorHandler`
// that takes in a `RoutingError` and returns a `Response`? What's the right
// interface here?
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 {
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
}
Allow different lifetimes in handler Request reference and its contents.
2016-10-07 03:38:13 +00:00
pub fn handle<'b, 'r>(&self, err: Error, request: &'b Request<'r>) -> Response<'b> {
Improve default catcher error messages.
2016-09-09 08:00:51 +00:00
(self.handler)(err, request)
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
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
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
}
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">
Add a default template for every known error code.
2016-10-08 04:31:52 +00:00
<h1>"#, $code, " ", $name, r#"</hi>
<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
$(
fn $fn_name<'r>(_: Error, _r: &'r Request) -> Response<'r> {
Response::with_status(
StatusCode::Unregistered($code),
data::HTML(error_page_template!($code, $name, $description))
)
}
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;
use response::Response;
use response::data;
use error::Error;
use http::hyper::StatusCode;
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,
403, "Forbidden", "The request was forbidden by the server.
Check authentication.", handle_403,
402, "Payment Required", "The request could not be processed due to lack of
payment.", handle_402,
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