Yeah, probably smart to have :-)

Hi @MindFlavor thanks for the detailed response.

I suggest for the time being to update the readme, I find it still often is not commonly known how to reference a git repo directly without using crates. And also giving this disclaimer you just gave.

I prefer regular updates - more agile, if you will - as long as the lib is not called 1.0. To be honest I would even consider already starting where this lib is at right now with some 0.1 release on crates, cause it makes much simpler for people to work with. If I want to not get any breaking change I can pin to a specific release and the git-ref is still there as a fallback.

My current project is actually building upon this lib to access azure blob storage in production in the coming weeks and I would like to migrate to this repo as soon as possible.

Hi extrawurst, sorry for the confusion. The release crates refer to the old, archived, repo (and no longer maintained as you have noticed). All the development currently happens here.

This repo is still in the "incubation" phase. We are deciding the final approach for request builders, http clients, etc... and we do not yet have a release schedule.

For the time being I suggest you to reference the repo directly. I'll leave the issue open to update you on this topic.

By the way, would you prefer a rigorous release schedule or a more relaxed one (and possibly more agile)?

This PR moves all Cosmos resources (e.g., Users, Documents, Databases, etc.) into their own module. This makes some imports a bit longer, but we'll clean that up in the next PR.

This PR exposes the azurite_workaround feature and recognizes enpoint URIs from the storage connection string.

The azurite storage emulator requires specific configurations that are already available in the source code of the storage crate. The feature is not exposed, to be used though.

Endpoint URIs can be specified in the storage connection string. Currently they are ignored and replaced with hard-coded default values pointing to the azure blob storage. This is relevant when using the azurite storage emulator, where the account names can be modified (since version 3). The "with_emulator" method with hard coded value is no longer sufficient if account names are customized.

this is based on #157. the changes in this pr are d80934dc2d62d1729505c88febc6a55b7cb376fa

<br/>Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.<br/><br/>:x: cschaible sign now<br/>_{You have signed the CLA already but the status is still pending? Let us recheck it.}

This PR exposes the azurite_workaround feature and recognizes enpoint URIs from the storage connection string.

The azurite storage emulator requires specific configurations that are already available in the source code of the storage crate. The feature is not exposed, to be used though.

Endpoint URIs can be specified in the storage connection string. Currently they are ignored and replaced with hard-coded default values pointing to the azure blob storage. This is relevant when using the azurite storage emulator, where the account names can be modified (since version 3). The "with_emulator" method with hard coded value is no longer sufficient if account names are customized.

Hi @yoshuawuyts thank you very much for your review. I am pretty much in line globally.

Assume the RangeUnit is always bytes?

The RFC states that RangeUnits can be expected to be expanded in the future through RFC. Though in the past 6 years this has not happened, which makes it questionable to which degree we need to consider this. We could make the assumption that the only two types that may ever be sent are "none" and bytes.

I initially worked on a version with a RangeUnit enum, like the one you mentioned, opening the door to other range units if the RFC evolves in the future. But I realized that this is a lot of boilerplate for every day use since only bytes unite are used today in practice. So I went for a compromise with this Byte prefix thing which is not very much satisfying at the end, I agree.

Instead I would like to suggest switching it around: create a RangeUnits enum which is tagged #[non_exhaustive] and None and Bytes members, and then have Range , ContentRange, and AcceptRanges headers. This will allow us to add more range types in the future without breaking anything.

I would go for that design too, but I am not sure about having None as an enum variant: None is not a range unit type. It is a possible value for the AcceptRanges header to notify that range requests are not accepted, but it is not used otherwise for Range and ContentRange headers. We could have AcceptRanges::from_headers return Ok(None) if the Accept-Range header has the none value, without any impact client side.

However, by removing None from the enum we would have only one variant which looks strange too.

A third option would be something like:

enum RangeUnit {
    Bytes
    Other(String)
}

This allows for usage of non standard units, but not great either.

If we go for the RangeUnit design we will need to handle it with the Range and ContentRange headers too. Those type do not only returns a range unit but also a range set (ByteRanges in my current implementation) and a single Range. At the end I do not see how we can avoid several if let and match code for the end user using only bytes unit in practice. Do you have something in mind that could help here ?

suffix-length

I was reading about ranges on mdn and I'm confused about how the suffixes are exposed in our API? Do you have a good sense of how they work, and how we could implement them?

You can see them as relative seek from either start or end. So far I do not provide further helper over it, I am just exposing them with an optional value. In Tide we will have to match over them to either SeekFrom::Start or SeekFrom::End. We can extend the type with further helper functions if need be without a breaking change I believe.

Conclusion

Despite having feedback on some of the design, I think we're very well on our way to getting where we need to be! — I'm incredibly excited for this work, and how it'll enable us to implement http-rs/tide#687. Thanks so much for your work on this!

Thank you for your great feedback. This leaves us with the following choices:

1. We provide implementation for bytes unit only, and we fully assume a breaking change will probably need to be introduced if a new unit is added to the RFC. This is a limited risk at the benefit of simple code covering 100% of usage for the last 6 years.
2. We go for a RangeUnit enum #[non_exhaustive], at the benefit of allowing a source compatible introduction of a new unit, but at the risk to "complexify" the API for every day use.

Not an easy decision. A little daemon on my left shoulder says "come on, take the challenge and go with those damn enums, you are a rustacean or not ?", a little angel on my right shoulder says "come on, you know this is over-engineering, right ?"

Do you want me to have a try with the RangeUnit enum design to see how it goes, or you want to listen to the little angel ? In the latter case I will rename ByteRanges to Range and ByteRange to RangeItem (or any better name you might have), and simplify the API to handle bytes only.

What do you think ?

After this we need to talk about this comment which could impact the design of the If-Range header. But one discussion at a time :)

Example repo: https://github.com/Enigmatrix/winrt_workspace_test

Building the above repo gives an error when importing any type. e.g. in the case above,

Hello, also running into this issue while making a reqwest blocking call to several websites. I'm a relatively new rust user (4 months). Working on a bot that completes purchases on several websites. I'm getting this error when I make the request: I am working on MacOS Big Sur. I wrote my code first in python and now I'm rewriting in rust. My reqwest calls work perfectly in python, but I'm having problems in Rust. Any pointers?

@richardanaya default not-found handling is a known issue with serve_dir. until we add a way to configure serve_dir, you probably want something like:

#[async_std::main]
async fn main() -> Result<(), std::io::Error> {
    tide::log::start();
    let mut app = tide::new();

    app.with(tide::utils::After(|response: tide::Response| async move {
        if response.status() == tide::StatusCode::NotFound {
            Ok(tide::Response::builder(200)
                .body(tide::Body::from_file("./dist/index.html").await.unwrap())
                .build())
        } else {
            Ok(response)
        }
    }));

    app.at("/").serve_dir("./dist")?;

    app.listen("127.0.0.1:8080").await?;

    Ok(())
}

@jbr thanks for your comments! I looked at serve_dir. I think part of me just didn't know this existed. The logic I was trying to implement fundamentally was:

1. listen to all paths /*
2. does this path exist realtive to a certain directory?
3. if I didn't exist, how do I provide a fallback.

I see now how serve dir could handle 1 & 2

app.at("/*").serve_dir("dist/")?;

not yet sure about #3 :) my assumption is a fallback route exists somewhere though