This ended up getting reverted by #1367, which re-introduced an unsound
use of `Pin::new_unchecked`
See my original PR #1374 for the reasoning behind this change.
- Convert MessageBody to accept Pin in poll_next
- add CHANGES and increase versions aligned to semver
- update crates to accomodate MessageBody Pin change
- fix tests and dependencies
* Moved actix-http for actix from actix crate
* remove resolver feature
* renamed actix feature to actor
* fixed doc attr for actors, add documentation
This removes the last uses of unsafe `Pin` functions in actix-web.
This PR adds a `Pin<Box<_>>` wrapper to `DispatcherState::Upgrade`,
`State::ExpectCall`, and `State::ServiceCall`.
The previous uses of the futures `State::ExpectCall` and `State::ServiceCall`
were Undefined Behavior - a future was obtained from `self.expect.call`
or `self.service.call`, pinned on the stack, and then immediately
returned from `handle_request`. The only alternative to using `Box::pin`
would be to refactor `handle_request` to write the futures directly into
their final location, or avoid polling them before they are returned.
The previous use of `DispatcherState::Upgrade` doesn't seem to be
unsound. However, having data pinned inside an enum that we
`std::mem::replace` would require some careful `unsafe` code to ensure
that we never call `std::mem::replace` when the active variant contains
pinned data. By using `Box::pin`, we any possibility of future
refactoring accidentally introducing undefined behavior.
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
Fixes#1321
A better fix would be to change `MessageBody` to take a `Pin<&mut
Self>`, rather than a `Pin<&mut Self>`. This will avoid requiring the
use of `Box` for all consumers by allowing the caller to determine how
to pin the `MessageBody` implementation (e.g. via stack pinning).
However, doing so is a breaking change that will affect every user of
`MessageBody`. By pinning the inner stream ourselves, we can fix the
undefined behavior without breaking the API.
I've included @sebzim4500's reproduction case as a new test case.
However, due to the nature of undefined behavior, this could pass (and
not segfault) even if underlying issue were to regress.
Unfortunately, until rust-lang/unsafe-code-guidelines#148 is resolved,
it's not even possible to write a Miri test that will pass when the bug
is fixed.
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
* Enforce safety of `downcast_ref` at compile time.
The safety of `downcast_ref` requires that `__private_get_type_id__` not
be overriden by callers, since the returned `TypeId` is used to check if
the cast is safe. However, all trait methods in Rust are public, so
users can override `__private_get_type_id__` despite it being
`#[doc(hidden)]`.
This commit makes `__private_get_type_id__` return a type with a private
constructor, ensuring that the only possible implementation is the
default implementation. A more detailed explanation is provided in the
comments added to the file.
Note that the standard library was affected by this type of issue with
the `Error::type_id` function: see https://blog.rust-lang.org/2019/05/14/Rust-1.34.2.html#whats-in-1.34.2-stable
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
* Replace `UnsafeCell` with `Cell` in `DateServiceInner`
This ensures that it's impossible to cause undefined behavior by
accidentally violating Rust's aliasing rules (e.g. passing a closure to
`set_date` which ends up invoking `reset` or `update` on the inner
`DateServiceInner`).
There might be a tiny amount of overhead from copying the `Option<(Date,
Instant)>` rather than taking a reference, but it shouldn't be
measurable.
Since the wrapped type is `Copy`, a `Cell` can be used, avoiding the
runtime overhead of a `RefCell`.
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
* Use `OffsetDateTime` instead of `PrimitiveDateTime`
* Parse time strings with `PrimitiveDateTime::parse` instead of `OffsetDateTime::parse`
* Remove unused `time` dependency from actix-multipart
* Fix a few errors with time related tests from the `time` upgrade
* Implement logic to convert a RFC 850 two-digit year into a full length year, and organize time parsing related functions
* Upgrade `time` to 0.2.2
* Correctly parse C's asctime time format using time 0.2's new format patterns
* Update CHANGES.md
* Use `time` without any of its deprecated functions
* Enforce a UTC time offset when converting an `OffsetDateTime` into a Header value
* Use the more readable version of `Duration::seconds(0)`, `Duration::zero()`
* Remove unneeded conversion of time::Duration to std::time::Duration
* Use `OffsetDateTime::as_seconds_f64` instead of manually calculating the amount of seconds from nanoseconds
* Replace a few additional instances of `Duration::seconds(0)` with `Duration::zero()`
* Truncate any nanoseconds from a supplied `Duration` within `Cookie::set_max_age` to ensure two Cookies with the same amount whole seconds equate to one another
* Fix the actix-http:🍪:do_not_panic_on_large_max_ages test
* Convert `Cookie::max_age` and `Cookie::expires` examples to `time` 0.2
Mainly minor changes. Type inference can be used alongside the new
`time::parse` method, such that the type doesn't need to be specified.
This will be useful if a refactoring takes place that changes the type.
There are also new macros, which are used where possible.
One change that is not immediately obvious, in `HttpDate`, there was an
unnecessary conditional. As the time crate allows for negative durations
(and can perform arithmetic with such), the if/else can be removed
entirely.
Time v0.2.3 also has some bug fixes, which is why I am not using a more
general v0.2 in Cargo.toml.
v0.2.3 has been yanked, as it was backwards imcompatible. This version
reverts the breaking change, while still supporting rustc back to
1.34.0.
* Add missing `time::offset` macro import
* Fix type confusion when using `time::parse` followed by `using_offset`
* Update `time` to 0.2.5
* Update CHANGES.md
Co-authored-by: Jacob Pratt <the.z.cuber@gmail.com>
* Skip empty chucks for BodyStream and SizedStream when streaming response (#1267)
* Fix tests to fail on previous implementation
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
Most of the relevant struct already had a `#[pin_project]` attribute,
but it wasn't being used.
The remaining uses of `Pin::new_unchecked` all involve going from a
`&mut T` to a `Pin<&mut T>`, without directly observing a `Pin<&mut T>`
first. As such, they cannot be replaced by `pin_project`
Co-authored-by: Yuki Okushi <huyuumi.dev@gmail.com>
