Prior to this commit, 'Vec', 'HashMap', and 'BTreeMap' would parse
leniently irrespetive of the requested parsing strategy. This commit
changes their behavior so that the parsing strategy is respected.
Resolves#2131.
In cc98f98, logging was changed to use a new 'write_out!' macro that
internally used 'write!' instead of 'print!' to log. This had an
unfortunate side-effect: 'libtest' via 'cargo test' no longer captures
the log output of tests.
The reason this occurs is due to the way that Cargo, or rather
`libtest`, captures log output: it uses hidden, unstable functions that
replace a special sink that `print!`, and _only_ `print!` writes to.
Using `write!` directly, as the commit does, bypasses this sink, and so
`cargo` never captures the output.
As a compromise, we only use the better implementation when we're not
compiled with `debug_assertions` or running tests, so at least tests run
in debug-mode won't spew output.
Also updates 'tokio-rustls' to a compatible version.
Additionally depends on 'rustls-pemfile' which includes functionality
that was previously part of 'rustls' itself.
This commit removes the 'CookieJar::get_private_pending()' method in
favor of the already existing and correct 'CookieJar::get_pending()'
method. Previously, the 'CookieJar::get_private_pending()' method
attempted to decrypt the value of a pending cookie, which in reality is
plaintext, thus failing. Because the pending value is plaintext, the
'CookieJar::get_pending()' method suffices.
Documentation has been updated to refer to 'CookieJar::get_pending()'.
Fixes#2063.
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 primary aim of this commit is to reduce confusion between
'content::Json' and 'rocket::serde::json::Json' be renaming the former
to 'content::RawJson'. The complete changes in this PR are:
* All responders in the 'content' module are prefixed with 'Raw'.
* The 'content::Custom' responder was removed entirely.
* The 'Plain' responder is now 'RawText'.
* The 'content' API docs point to the 'serde' responders.
* The docs and examples were updated accordingly.
Previously, TLS, via 'Config::tls', was configurable even if the 'tls'
feature was disabled. This commit changes this so that the 'Config::tls'
field and TLS config structures are only available if 'tls' is enabled.
Instead of a constructor, 'MediaType::with_params()' and
'ContentType::with_params()' are now both builder methods. This allow
chaining the method to associated constants.
As 'FromForm' doesn't provide access to the raw, undecoded string,
'MsgPack' cannot implement 'FromForm::from_value()'. This means that it
is not presently possible to parse a MessagePack form from a query
string. As such, the 'UriDisplay<Query>' implementation was removed.
The 'UriDisplay<Query>' for JSON was fixed such that a round-trip of a
'Json<T>' as a form works as expected.
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 'Json' type now implements:
* Clone
* PartialEq
* Eq
* PartialOrd
* Ord
* Hash
* UriDisplay<Query>
Method calls that resolve to a method in the set of traits above
previously resolved to the `Deref` target. For example, `foo.clone()`,
where `foo: Json<T>`, previously resolved to `<T as Clone>::clone()` but
now resolves to `<Json<T> as Clone>::clone()`.
'Missing' allows constructing a 'FileServer' even if the supplied path
does not exist. 'IndexFile' allows serving a single file as the index of
the mount path.
The syntax 'TypedStream![T + '_]' expands to:
impl TypedStream<Item = T> + '_
This allows seamlessly borrowing in typed streams.
Also adds 'Event::empty()', for convenience.
The improvements are:
* Point directly and immediately to the 'Responder' derive.
* Provide more discussion on lifetimes.
* Format documentation for easier scanning.
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.
If stars aligned properly, we might imagine writing this:
#[non_exhaustive]
struct Config {
pub field: Foo,
pub other: Bar,
}
...with semantics that would allow the defining crate (here, Rocket), to
construct the structure directly while consumers would need to use
public constructors or struct update syntax:
Config {
field: Foo,
other: Bar,
..Default::default()
}
Alas, this is not the way `non_exhaustive` works on structs. You cannot
use field-update syntax to construct `Config` above. You must use public
constructors. This means builder methods or mutating an already built
struct. This is not what we want.
I don't know why it works this way. I don't see why it must. Something
something Drop.
So we have this hack from the pre-non_exhaustive era.
This resolves syntax ambiguity issues with public typed-stream macros.
Prior to this commit, greedy single-token matching by macro-rules macros
would result in certain tokens at the beginning of the macro input, such
as 'for', inadvertently triggering a '$ty' matching case resulting in
incorrect expansion.
This commit makes the following improvements to core request handling:
* Absolute target URIs are not rejected. Instead, the path and query
parts are passed through the application. This resolves an issue
where certain HTTP/2 requests would be rejected by Rocket.
* Data is never copied from the request. Previously, Rocket would copy
and allocate for incoming headers.
* Non-UTF-8 headers are dropped with a warning instead of being
lossily, and thus perhaps incorrectly, decoded as UTF-8. The final
fix is to properly support non-UTF-8 headers, no matter how in the
minority they are.
Resolves#1498.