Sessions
--------
This commit removes the `Session` type in favor of methods on the
`Cookies` types that allow for adding, removing, and getting private
(signed and encrypted) cookies. These methods provide a superset of
the functionality of `Session` while also being a minimal addition to
the existing API. They can be used to implement the previous `Session`
type as well as other forms of session storage. The new methods are:
* Cookie::add_private(&mut self, Cookie)
* Cookie::remove_private(&mut self, Cookie)
* Cookie::get_private(&self, &str)
Resolves#20
Testing
-------
This commit removes the `rocket::testing` module. It adds the
`rocket::local` module which provides a `Client` type for local
dispatching of requests against a `Rocket` instance. This `local`
package subsumes the previous `testing` package.
Rocket Examples
---------------
The `forms`, `optional_result`, and `hello_alt_methods` examples have
been removed. The following example have been renamed:
* extended_validation -> form_validation
* hello_ranks -> ranking
* from_request -> request_guard
* hello_tls -> tls
Other Changes
-------------
This commit also includes the following smaller changes:
* Config::{development, staging, production} constructors have been
added for easier creation of default `Config` structures.
* The `Config` type is exported from the root.
* `Request` implements `Clone` and `Debug`.
* `Request::new` is no longer exported.
* A `Response::body_bytes` method was added to easily retrieve a
response's body as a `Vec<u8>`.
This is a breaking change.
The `testing` feature no longer exists. Testing structures can now be
accessed without any features enabled.
Prior to this change, Rocket would panic when draining from a network
stream failed. With this change, Rocket force closes the stream on any
error.
This change also ensures that the `Fairings` launch output only prints
if at least one fairing has been attached.
This is a (minor) breaking change. If `rocket.launch()` is the last expression
in a function, the return type will change from `()` to `LaunchError`. A simple
workaround that preserves the previous functionality is to simply add a
semicolon after `launch()`: `rocket.launch();`.
resolves#34
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?
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.
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?
Sergio Benitez
Reilly Tucker Siemens
Sergio Benitez