Should there be a Url (L as in "llama") type, or some (optional) interop with the url crate?

[ragnese]

In the docs for Uri, it mentions that a Uri doesn't necessarily have a scheme and host. But, if we do want a type that is guaranteed to have a host and scheme, then we want to use something like url::Url.

Perhaps it would be nice to add an optional feature to this crate to add the url crate as a dep and re-export its types. And then maybe add some extensions/etc to make going back and forth between Uri and Url convenient.

Thoughts?

[seanmonstar]

This was discussed a bit in #73. In short, we don't want to tie the stability of http with that of url, and conversion between the two is possible without it.

[ragnese]

I apologize for not seeing that issue before posting this question.

I think that's a fair conclusion with respect to (optionally) depending on the url crate.

It's definitely not a big deal to convert back and forth if we do want to use both types in a project (the only "missing" piece is that we know a conversion from Url -> Uri should never fail).

Though, I still wonder if there are some use cases where it would make sense for this crate's Uri type to indicate whether it's a valid absolute URL.

Or is that out of scope for this crate because it's intended to be for server-side and only a client would care/need a "full" URL?

[seanmonstar]

The type is intended for both server and client side HTTP. So, for instance, it can represent a CONNECT request, with only the host, or it can represent an OPTIONS request with just *. Both of those aren't legal Urls.

What did you have in mind about checking if it is absolute? I guess if you check that the scheme and authority are set, it would be an absolute URL, right?

[damooo]

This type http::Uri is actually http-request-target (#523 ), is it correct to say that @seanmonstar ?

[ragnese]

What did you have in mind about checking if it is absolute? I guess if you check that the scheme and authority are set, it would be an absolute URL, right?

Yes, as far as I understand it, it would be absolute if it has the scheme and authority set.

Fair point about the CONNECT and OPTIONS requests. I didn't know that those supported URIs that were not technically URLs from the client side.

For my specific use-case, I actually do what you mentioned earlier and convert between a url::Url and a http::Uri. My project needs to expect network connectivity to be flaky and we need to try to not lose any requests. Therefore, my code tries to send these requests, and if the request fails, I serialize and persist the "RequestInfo" (so that reboots or loss of power doesn't destroy unsent requests) to be retried at some time in the future. The struct that I persist is defined with a url::Url field specifically so I won't mistakenly create one with an unsendable URL. I use http::Uri (and other http types) in other places, and just thought it would be nice to have a type-level differentiation between a Uri, which is useful for the server-y stuff, and also a Url that is statically known to be good for client-y stuff.

It's a pretty trivial problem, I admit. I could easily write my own "newtype" around http::Uri that checks the scheme and authority, I can continue using url::Url and converting back-and-forth, or I can just write a check in the constructor of my serializable RequestInfo struct.

I just figured that since url seems to be a fairly popular crate, it might be helpful to other users to throw it in as an optional dependency with two trivial conversion functions between Url and Uri.