Remove Url depedency

[seanmonstar]

Now that hyper::Uri has sufficient parsing capability, and can represent any URI for the server or client, does it make sense to still also use the Url type? When looking at the rustdocs generated, it certainly looks confusing that there is both Url and Uri at the crate root. And issues like #1087 and others sometimes appear because people assume hyper controls the Url type.

Some options I'm considering:

• Remove any direct usage of Url, but implement From<Url> for Uri, so people can easily do Request::new(Get, url.into()).
• Remove the url crate dependency entirely. This would probably be the ideal option, so that the crate is only included in projects that explicitly ask for it. However, it does make it slightly more annoying to create client requests.

/cc @frewsxcv @nox (@alexcrichton for sccache experience)

[alexcrichton]

At least for me in how I've worked with libs in the past it's pretty rare for me to have a parsed Url on hand. Typically I manage it via a string and then just pass it to a library (there's also typically very little manipulation of the URL as well).

I could go either way, but in some sense reducing the suite of public dependencies is always a nice win! (if necessary though I'd definitely still use it for internal usage if the need arose)

[seanmonstar]

hyper no longer makes use the of the Url type internally anywhere. It's only usage at this point is in client::Request, for setting the target of the Request, and in the generic Connect type that Client uses.

The Connect trait is basically an alias for Server<Request=Url, Response=T> where T: Io.

---

So, hyper could remove the public re-export, and change Client and client::Request to make use of hyper::Uri. That looks like the right direction to go.

My last remaining question is whether there is value in implementing From<Url> for Uri, since it'd be a near-free conversion, and people who do have a Url could then do client.get(url.into()).

[timokau]

Will you implement From<Url> for Uri? Or how would you recommend converting between the two types?
As a quick hack Uri::from_str(&url.to_string()).unwrap()) works, but thats unnecessarily costly and requires an unwrap.

[seanmonstar]

At least not for now. I expect something like reqwest will allow both types, to ease usage.

For now, you can reduce some of the cost by just using a reference to the Url: Uri::from_str(url.as_ref()).unwrap()

[timokau]

Okay, thank you.

[Kerollmops]

Can I ask why you choose to remove the Url crate (kind of Rust-official) and not the Uri one ? What are the advantages of Uri hover Url ?

I don't understand why being less generic is a good thing in this case ?
Users working with multiple web-libraries (or just libraries that works with Urls) will need to depends on multiple structs representing the same type of data, useless and not efficient, don't you think ?