This commit asserts that continuation frames are an implementation
detail of the websocket layer, and should remain hidden from the
application layer. That is:
- a codec should write only frames to the wire, and read only frames from the wire
- when sending messages, the websocket implementation should break large
text and binary messages into continuation frames -- the application should
not have to be aware of this.
- when receiving messages, the websocket implementation should reconstitute
continuation frames into their original messages -- the application should
not have to handle this.
- the application should only have to send and receive complete websocket messages
Here, the reconstitution of continuation frames into their original messages is
done by the Stream implementation of actix_web_actors::ws::WsStream, by adding
a continuation frame buffer and not issuing a Poll::Ready(Some(Ok)) result until
a complete message has been buffered. A test in actix_web_actors::tests::test_ws.rs
checks this.
The breaking of large message payloads into sequential continuation frames is
done by the addition of an actix_http::ws::frame_iters module, which introduces
two structs ContinuationBins and ContinuationTexts. These are iterators over
either single Frame::Binary or Frame::Text frames, if the payloads are small,
or over sequences of Frame::Continuation's with appropriate Items FirstBinary/FirstText,
Continue, and Last. New tests in actix_http::ws::frame_iters verify this
functionality.
For allowing a more ergonomic use and better integration on the
ecosystem, this adds the `std::error::Error` `impl` for our custom
errors.
We intent to drop this hand made code once `derive_more` finishes the
addition of the Error derive support[1]. Until that is available, we
need to live with that.
1. https://github.com/JelteF/derive_more/issues/92
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
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>
Huston Bokinsky
Yuki Okushi
Otavio Salvador
Maxim Vorobjov
Aaron Hill
Rob Ede
Daniel YU
zero-systems