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
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>
* Initial commit
* Added extra_headers
* Added freeze() method to ClientRequest which produces a 'read-only' copy of a request suitable for retrying the send operation
* Additional methods for FrozenClientRequest
* Fix
* Increased crates versions
* Fixed a unit test. Added one more unit test.
* Added RequestHeaderWrapper
* Small fixes
* Renamed RequestHeadWrapper->RequestHeadType
* Updated CHANGES.md files
* Small fix
* Small changes
* Removed *_extra methods from Connection trait
* Added FrozenSendBuilder
* Added FrozenSendBuilder
* Minor fix
* Replaced impl Future with concrete Future implementation
* Small renaming
* Renamed Send->SendBody
* Support to set header names of `ClientRequest` as Camel-Case
This is the case for supporting to request for servers which don't
perfectly implement the `RFC 7230`. It is important for an app
which uses `ClientRequest` as core part.
* Add field `upper_camel_case_headers` to `ClientRequest`.
* Add function `set_upper_camel_case_headers` to `ClientRequest`
and `ClientRequestBuilder` to set field `upper_camel_case_headers`.
* Add trait `client::writer::UpperCamelCaseHeader` for
`http::header::HeaderName`, let it can be converted to Camel-Case
then writed to buffer.
* Add test `test_client::test_upper_camel_case_headers`.
* Support upper Camel-Case headers
* [actix-http] Add field `upper_camel_case_headers` for `RequestHead`
* [actix-http] Add code for `MessageType` to support upper camel case
* [awc] Add functions for `ClientRequest` to set upper camel case
* Use `Flags::CAMEL_CASE` for upper camel case of headers
