Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Compilation Errors, Add Stable Rust Support, Improve Compatibility, and Implement Futures::io Traits #4

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

rrauch
Copy link

@rrauch rrauch commented Aug 21, 2024

reqwest-file has been really useful for my projects, and over time I've made several updates to keep it it that way. This PR includes those cumulative changes.

Main Changes

Fixed Compilation Errors on Recent Nightly

Since the nightly release on 2024-06-13, compilation has been failing with the error 'error: item does not constrain ... but has it in its signature'. This is due to changes in TAIT handling. You can find more details here.

To fix this, I moved the TAIT declarations and the send_request function into their own submodule. This gets everything compiling again.

Added Stable Rust Support

I've made some updates to get reqwest-file to compile on stable Rust. This involved a bit of boxing, but nothing major. The original code is still there and is now behind a new nightly feature flag. By default, it will now work on stable Rust.

Improved Range Request Header

Previously, reqwest-file always sent the Range request header like this:

bytes={offset}-

While this is perfeclty spec-compliant, I ran into a server that expects an end value. The updated code will send a header like this if the size is known:

bytes={offset}-{size-1}

If the size isn't known, the open-ended value is sent as before. This should improve compatibility without any drawbacks.

Support for futures_util::io::{AsyncRead, AsyncSeek}

In addition to tokio::io::{AsyncRead, AsyncSeek}, RequestFile now also implements futures_util::io::{AsyncRead, AsyncSeek}. These traits are quite similar, but projects that don't use Tokio might prefer the futures traits. The supported traits can be toggled with the tokio_io and futures_io feature flags. Only one can be enabled at a time, however. When using futures_io, there are no Tokio dependencies.

I've restructured the code slightly to avoid duplicate code due to the multiple code paths. All tests still pass 100% in all configurations (with tokio_io & futures_io, both with and without nightly). I've also updated the dependencies.

…or: item does not constrain ... but has it in its signature'. This is caused by changes in TAIT handling. This commit works around that and fixes the compilation error
…n. Nightly functions remain intact behind the `nightly` feature flag.
…mpatibility with non-spec conforming servers
… addition to the existing `tokio::io::{AsyncRead, AsyncSeek}` support. The feature flags `tokio_io` and `futures_io` can be used to select which one should be in use. This is either/or. Enabling both or neither leads to a descriptive compilation error.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant