This commit also adds the `base` field to `Route` which allows the
base mount point to be retrieved. Finally, this commits adds an
implementation of `FromRequest` for `Route` which returns the active
route if one is available or forwards otherwise.
This commit is a breaking change: it makes `Request` and `MockRequest`
invariant over the lifetime `'r`. While this shouldn't affect most
applications, it may affect some.
Resolves#108.
This is a breaking change. It modifies collisions with respect to query
parameters as well as the default ranking of routes.
A route that does not specify query parameters will now match against
requests with _and without_ query parameters, assuming all other
elements of the route match as well. A route that _does_ specify query
parameters will only match requests with query parameters; this remains
true.
To accommodate this change in the most natural manner possible, the
default rankings of routes have changed as illustrated below:
|-------------+-------+----------+---------------|
| static path | query | new rank | previous rank |
|-------------+-------+----------+---------------|
| yes | yes | -4 | 0 |
| yes | no | -3 | 0 |
| no | yes | -2 | 1 |
| no | no | -1 | 1 |
|-------------+-------+----------+---------------|
In other words, the most specific routes, with preference for paths over
queries, are ranked highest (lower number).
This commit changes the routing algorithm. In particular, it enforces
precise matching of formats. With this change, a route with a specified
format only matches requests that have the same format specified. A
route with no format specified matches any request's format. This is
contrast to the previous behavior, where a route without a specified
format would match requests regardless of their format or whether one
was specified.
This commit also changes the following:
* The return type of the 'content_type' method of 'Request' is now
'Option<ContentType>'.
* The 'ContentType' request guard forwards when the request has no
specified ContentType.
* The 'add_header' and 'replace_header' methods take the header
argument generically.
Closes#120.
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`.
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.
Here's the idea: under the `Rocket` namespace should live things critical to
writing simple Rocket apps: Request, Response, Error, etc. Nothing should be
nested more than one level deep. Only items required for more complex things
(implementing uncommon traits, etc.) should be nested one level deep.
This commit is the first attempt at realizing this.
There's something going on with Hyper. When a 303 (see other) response is sent
in response to a POST, the browser does a GET to the location header. Hyper
somehow misreads the method parameter here, resulting in a route failer.
I need to MITM the connection to see exactly what the browser is sending and
what Hyper is receiving to see who's wrong.
Okay, so, given a URI, we can figure out which route is corresponds to.
Unfortunately, the handler is not yet part of that route, and we're not parsing
the parameters from the path quite yet. But, we're almost there!
Sergio Benitez
Sergio Benitez