Fix Compilation Errors, Add Stable Rust Support, Improve Compatibility, and Implement Futures::io Traits #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 newnightly
feature flag. By default, it will now work on stable Rust.Improved
Range
Request HeaderPreviously,
reqwest-file
always sent theRange
request header like this: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:
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 implementsfutures_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 thetokio_io
andfutures_io
feature flags. Only one can be enabled at a time, however. When usingfutures_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 withoutnightly
). I've also updated the dependencies.