This commit introduces TLS support, provided by `rustls` and a fork of
`hyper-rustls`. TLS support is enabled via the `tls` feature and
activated when the `tls` configuration parameter is set. A new
`hello_tls` example illustrates its usage.
This commit also introduces more robust and complete configuration
settings via environment variables. In particular, quoted string,
array, and table (dictionaries) based configuration parameters can now
be set via environment variables.
Resolves#28.
This is a breaking change.
This commit introduces `RawStr` to forms. In particular, after this
commit, the `&str` type no longer implements `FromFormValue`, and so it
cannot be used as a field in forms. Instad, the `&RawStr` can be used.
The `FormItems` iterator now returns an `(&RawStr, &RawStr)` pair.
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
This commit involves several breaking changes:
* `session_key` config param must be a 256-bit base64 encoded string.
* `FromRequest` is implemented for `Cookies`, not `Cookie`.
* Only a single `Cookies` instance can be retrieved at a time.
* `Config::take_session_key` returns a `Vec<u8>`.
* `Into<Header>` is implemented for `&Cookie`, not `Cookie`.
This commit changes the way Rocket parses form items. In particular, it now
(liberally) validates form strings, returning a Bad Request on malformed inputs
and Unprocessable Entity on bad parses.
The 'FormItems' iterator was modified to accomodate this. The iterator is now
initialized using 'from': 'FormItems::from(form_string)'. The iterator can be
queried to check for a complete parse using either 'completed()' or
'exhausted()', the latter of which will consume valid keys/values and return
true only if the entire string was consumed.
The 'FromForm' trait now takes a mutable borrow to a 'FormItems' iterator.
The 'Form' and 'FormForm' implementation for 'Form' were modified to use the new
iterfaces and check for 'exhausted' after a parse, returning a Bad Request error
if the iterator cannot be exhausted.
Resolves#46.
A few interesting notes on this breakage:
* `Cookie` how has a lifetime. It should be `'static'` everywhere.
* The `SetCookie` header is no longer reexported.
* Instead, `Cookie` implements `Into<Header>` for Set-Cookie.
* Add Config::new() and Config::build() for simpler Config creation.
* Add set_{param} methods to Config.
* Add ConfigBuilder type for easy building of configurations.
* Remove builder methods from Config.
* PartialEq in Config doesn't consider path or session key.
* Rocket::custom takes Config by value.
* Rocket::custom takes second (enable_logging) boolean argument.
* Rocket::custom properly sets the custom config as the active config.
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`.
This commit includes the following important API changes:
* The `form` route parameter has been removed.
* The `data` route parameter has been added.
* Forms are not handled via the `data` parameter and `Form` type.
* Removed the `data` parameter from `Request`.
* Added `FromData` conversion trate and default implementation.
* Added `DataOutcome` enum, which is the return type of `from_data`.
* 'FromData' is now used to automatically derive the `data` parameter.
* Moved `form` into `request` module.
* Removed `Failure::new` in favor of direct value construction.
This commit includes the following important package additions:
* Added a 'raw_upload' example.
* `manual_routes` example uses `Data` parameter.
* Now building and running tests with `--all-features` flag.
* All exmaples have been updated to latest API.
* Now using upstream Tera.
This commit includes the following important fixes:
* Any valid ident is now allowed in single-parameter route parameters.
* Lifetimes are now properly stripped in code generation.
* `FromForm` derive now works on empty structs.
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.
* All From* trait methods are now named like the trait.
* All From* traits have an associated Error type.
* Document all of the `form` module.
* Add codegen tests for auto-derived forms.
* The param parsing traits now live under Request.
* Add content-type responsers for JSON, HTML, and plain text.
* Use content-type responders in content_type example.
* Conditionally create Request `from` HypRequest.
* Clean-up dispatching and handling in main rocket.
* Change Level enum to Logging Level and reexport.
* Allow users to set logging level before launch.
* Fix content_type example error handling.
* Percent decode params when user requests `String`.
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?
Sergio Benitez
Sergio Benitez