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.
