Previously, the `NotFound` status code was used to signal many kinds of
recoverable, forwarding errors. This included validation errors, incorrect
Content-Type errors, and more.
This commit modifies the status code used to forward in these instances to more
precisely indicate the forwarding condition. In particular:
* Parameter `FromParam` errors now forward as 422 (`UnprocessableEntity`).
* Query paramater errors now forward as 422 (`UnprocessableEntity`).
* Use of incorrect form content-type forwards as 413 (`UnsupportedMediaType`).
* `WebSocket` guard now forwards as 400 (`BadRequest`).
* `&Host`, `&Accept`, `&ContentType`, `IpAddr`, and `SocketAddr` all forward
with a 500 (`InternalServerError`).
Additionally, the `IntoOutcome` trait was overhauled to support functionality
previously offered by methods on `Outcome`. The `Outcome::forward()` method now
requires a status code to use for the forwarding outcome.
Finally, logging of `Outcome`s now includes the relevant status code.
Resolves#2626.
The primary motivation is to deconflate the leading `F`s in `Failure` and
`Forward`. In particular, when using a generics, we used `F` for forward, which
could easily be confused for `F` for `Failure`. This resolves the conflation.
The warning is fairly conservative. Heuristics are used to determine if a call
to `tokio::spawn()` occurs in the `#[launch]` function.
Addresses #2547.
The codegen for field validations previously included a closure that
could potentially partially borrow a 'Copy' field of the context
structure. To prevent this, 'let'-assign the field before the closure is
created, and use the assignment inside of the closure.
Prior to this commit, all forward outcomes resulted in a 404. This
commit changes request and data guards so that they are able to provide
a `Status` on `Forward` outcomes. The router uses this status, if the
final outcome is to forward, to identify the catcher to invoke.
The net effect is that guards can now customize the status code of a
forward and thus the error catcher invoked if the final outcome of a
request is to forward.
Resolves#1560.
Previously, if a module used or defined a type alias for Result,
FromFormField derives would fail to compile as it would use the type
alias instead of the fully qualified type.
Prior to this commit, the `FromForm` derive could pair the incorrect
field name with a failing validation. The bug was caused by using two
mismatched iterators in a `quote!()` invocation. Specifically, the first
iterator emitted validation calls for all fields that had validation
applied, while the second emitted field names for all fields,
irrespective of whether the field had any validation applied. The two
iterators were effectively zipped to create the final error, creating
the bug.
This commit fixes the issue by correctly matching field names with their
validators at the expense of an additional allocation, necessitated by
the `quote` crate's inability to access subfields in a repetition.
Fixes#2394.
Due to tokio-rs/tokio#4780, a panicking top-level future combined with
an uncooperative background task prevents runtime shutdown. To avoid
this in the case of `Rocket::launch()` returning an `Error`, which
panics on drop if it isn't inspected, we return the `Result` to the
caller (i.e., `main`) instead of the `block_on` future. This prevent the
panic from occuring inside of the `block_on` future and so the runtime
terminates even with uncooperative I/O.
The core improvement is that `Rocket::launch()` now resolves to
`Ok(Rocket<Ignite>)` on nominal shutdown. Furthermore, shutdown never
terminates the running process.
Other changes directly related to shutdown:
* Runtime worker thread names are now irrelevant to graceful shutdown.
* `ErrorKind::Runtime` was removed; `ErrorKind::Shutdown` was added.
* The `force` config value is only read from the default provider.
* If `force`, Rocket's constructed async runtime is terminated.
Other related changes:
* The exported `hyper` module docs properly reflect public re-exports.
This commit implements a workaround for an [issue within rustc]. The
problem showed itself when using e.g. a `Vec<&str>` argument in an async
route handler (but not `&str`), which resulted in a "implementation of
`FromForm` is not general enough" error. The workaround itself works by
gathering all invocations of `FromForm`'s methods inside a block without
any `.await` points [ref].
[issue within rustc]: https://github.com/rust-lang/rust/issues/69663
[ref]: https://github.com/rust-lang/rust/issues/57478#issuecomment-501186084
The 'FromFrom' derive now allows type generics in all positions using
the same automatic discovery technique as with 'Responder'. (In fact,
the technique was created for this derive.) Furthermore, 'FromForm' can
now be derived for unit structs.
Also adds a new 'try_with' form field validator.
Resolves#1695.
This commit presents and applies a new technique for bounding type
generics in derives. In short, for a generic `T` used in a field type of
`Field<T>`, where an eventual bound of `Responder` required, the derive
generates a bound of `Field<T>: Responder`. This removes the need for
any manually provided bounds while simultaneously allowing more
structures to typecheck. For example, generics in header components are
now fully supported.
The syntax 'TypedStream![T + '_]' expands to:
impl TypedStream<Item = T> + '_
This allows seamlessly borrowing in typed streams.
Also adds 'Event::empty()', for convenience.
Previously, recursion into rewriting 'self' in field validations would
cease after the first function call. This meant that internal uses of
'self' were not properly rewritten. This commit ameliorates the
situation.
This allows responses to be sent to the client even when data is only
partially read, significantly improving the experience for the client
from one with a "connection closed" error to one with a proper response.
The consequence is a lifetime in 'Data'.
Though other non-lifetime-introducing solutions exist, the introduction
of a lifetime to 'Data' is a longstanding desire as it prevents
smuggling 'Data' into a longer-lived context. Use of 'Data' in that
context was unspecified with various runtime consequences. The addition
of a lifetime bound by the request prevents this error statically.
In summary, the changes are:
* Clients receive responses even when data isn't fully read.
* 'Data' becomes 'Data<'r>'. 'FromData' changes accordingly.
* Route 'Outcome's are strictly tied to the request lifetime.
Tangentially, the invalid length form field validation error message has
improved to format length in byte units if it exceeds 1024.