Comments (17)
I also want to chime in on this. It's pretty clear that the entire world is moving away from URI/IRI as terms to just URL. With the url crate we have a pretty damn good (new) standard compliant crate that is very popular. Right now I use this everywhere and then when doing requests to hyper I need to convert them which is not very great ergonomics and performance wise. I understand there are cases the url crate does not cover, but maybe at least transparent conversion from url
would be possible in cases where we are dealing with an actual url?
from http.
Given that several open issues are about URL handling, I'd suggest delegating to the url
crate, given that it's based on the modern battle-tested standard interoperable with other ecosystems (such as browsers, or HTTP servers that need to accept URLs from browsers.)
As for (U|I)R(|I|L|N), see https://url.spec.whatwg.org/#goals for why we've moved away from the URI term.
It would be unfortunate if a popular HTTP library for Rust goes in a different direction than Servo (or other web browsers) for URL handling.
from http.
The url
crate and the Uri
type provided by this crate handle different scenarios.
- The
url
crate explicitly only handles absolute URLs http::Uri
does not assume that the URL is stored as a string representation in contiguous memory.http::Uri
is able to acceptBytes
as input, allowing for zero-copy construction of values.
The url
crate is already at a 1.0 version and handling these issues would definitely be breaking. For example, http::Uri
does not provide an as_str()
fn.
That said, I think it would be plausible to provide conversions between http::Uri
and the url
crate.
from http.
Sorry if this was brought up before but something I'd love to see is something url’s query_pairs which gives you an iterator over the decoded set of query params. Also something like the form url encoded serializer type for appending params. I suggest these as convenience but also for ergonomics. It's very awkward to have to pull in another crate and wire two crate apis together to exercise a common action, parameterizing an http request.
from http.
So, this issue mentioned uri, with an i instead of L
I noticed, but I thought I'd just piggy back here.
Otherwise, thanks for the answer, makes sense too me.
from http.
I'd also be interested in why the url
crate is not used ( too complex? ) and what it's intended scope for the type is, as in, is it a conscious decision not to have any modifiers on Uri and will it stay this way, etc.
from http.
(For context, the issue originally mentioned the uri
crate, not url
.)
I had never heard of that crate before just now. I personally feel it's fine to continue to assume it doesn't exist. Crates with all sorts of names can show up. Any type that a user must use to interact with the http
crate will be in the docs. Other types can be assumed to be unrelated. :)
from http.
I'd also be interested in why the
url
crate is not used
So, this issue mentioned uri
, with an i
instead of L
, but I'll answer. The definition of URL
is too strict for all use cases of HTTP. All URLs are valid URIs, but the reverse is not true. For instance: https://hyper.rs/guides
is valid as both. /guides
is a valid URI, invalid URL. Same with *
. Same with hyper.rs
.
not to have any modifiers on Uri and will it stay this way, etc.
We started conservatively. It's more complicated to get setters to work correctly, especially since in most libraries, setters just allow passing any arbitrary string (such as uri.set_host("https://woops")
). Instead, for now, we've opted to have manipulation done elsewhere. Whenever you think you have a valid Uri
, you can parse it as one.
from http.
Er, oops. Yes, I mean the url crate. I should have noticed the rather low usage count and lack of dependent crates. Retitling and editing the issue, for the case I actually care about.
from http.
I've commented about the url
crate in this comment. I don't believe this crate is meant to replace it. The url
crate does much more parsing, and is meant to be used in Firefox (slightly stalled, but eventually).
My opinion is to just ignore that it exists. A user can turn any Url
into a string, and http::Uri
can parse strings.
from http.
A large number of crates already depend on Url though, we could possibly provide conversions (fallible in one direction), though something like the automatic features RFC would make this more appealing. I think this isn't a 0.1 blocker though.
from http.
Previous discussions on the hyper issue tracker regarding ergonomics and confusion regarding Uri
and Url
:
- Setters for
Uri
- Provide Conversion from url::Url to hyper::Uri
- Normalize trailing slash on Uri values
from http.
The Uri
type has different variants. In HTTP/1.x it will often only contain the path but in HTTP/2 most often the complete request Uri. In many cases clients and middleware will want to manipulate requests based on the request Uri
. What is the recommended way to do these things?
- On a server only set a response header if the request was send with HTTPS? For HTTP/2 the scheme is part of the
Uri
but in HTTP/1.x it is not part of the header. - Do routing with multiple hosts: Does every middleware need to implement its own logic or use some third-party crate to get the host? Both the
uri.authority()
and theHost
header may provide this information. - On a client: If the same function handles HTTP/1.x and HTTP/2 must all requests use the correct
Uri
/Host
combination for the version or is the client expected to convert fromUri
with:scheme
,:authority
and:path
toUri
with an absolute path and aHost
header and vice versa?
from http.
Yes, I wonder if server implementations should provide some sort of Uri normalization. Specifically, with HTTP 1.1, using the Host
header as the authority component. This would mirror how most HTTP client lib APIs look (you make a request to an URL, not a path + host header).
from http.
I'm astonished that no-one on this thread has reached out to the url crate authors. @SimonSapin, can you weigh in on the discussion here?
from http.
As far as I understand it’s not a replacement, they’re for different things.
As already mentioned, url::Url
represents an absolute URL record. Parsing a relative URL string such as "../foo.html"
requires providing a base URL to resolve against. The result always has an URL scheme/protocol, etc.
In my understanding, http::Uri
is something different. It is really the target of an HTTP request. This can be an absolute URL (compatible with url::Url
) but the more typical case is a host-relative URL like /foo.html
(starting with a slash). There’s other variants, like the single asterisk *
for some types of requests that only makes sense in the context of HTTP. Perhaps it should be name something like RequestTarget
instead.
I expect that a high-level HTTP client with a make_get_request(url: &url::Url) -> Something
API would not convert the entire url
to an absolute http::Uri
but instead extract the path and query components with something like &url[url::Position::BeforePath..url::Position::AfterQuery]
(after looking at other components to extract a SocketAddr
and a protocol).
from http.
@SimonSapin thanks for chiming in.
At this time, I do not believe that there are any steps to take regarding this issue. As such, I will close it. Feel free to explain why it should stay open and I can open it up again.
from http.
Related Issues (20)
- Clear contents of sensitive header values on drop HOT 2
- Why does canonical_reason() return a Option? HOT 3
- Rename 422 from "Unprocessable Entity" to "Unprocessable Content"
- const fn for `StatusCode::as_u16` HOT 1
- can't parse uri without scheme but having path HOT 4
- 1.0 vs 0.2 incompatibility HOT 1
- Allow customizing header casing
- Add a `Display` impl for `Request` and `Response` to reconstruct the raw HTTP message HOT 2
- impl std::error::Error for StatusCode HOT 1
- http::method::Method::FromStr implementation allows invalid methods, conflicting with from_str documentation HOT 2
- Invalid uri parse HOT 1
- `http::uri::Uri` is excessively large and makes unnecessary allocations HOT 2
- Failed to parse a valid url HOT 1
- Uri does not parse valid URIs with empty authority portion HOT 1
- Add 420 Enhance Your Calm status code
- How to append a queryparams string after using uri_mut().into_parts()? HOT 1
- `index out of bounds` when parsing a valid header value HOT 2
- Request headers containing Russian (and possibly other non-English) characters fail with `UTF-8 encoding error` HOT 1
- HeaderMap::try_with_capacity can panic when capacity is large
- RFC: Add `parts_mut() -> &mut Parts` to allow mutate parts directly HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from http.