-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: A username
method for Authority
#596
Comments
Huh, looks like let u : Uri = "mailto:someone@example.com".parse().unwrap();
assert_eq!(u.authority().unwrap().as_str(), "mailto:someone@example.com"); So while this should work, the fact that pub fn username_from_uri(uri: &Uri) -> Option<&str> {
let mut parts = uri.authority()?.as_str().rsplit('@');
parts.next().expect("split always yields at least one item");
parts.next()?.split(':').next()
} |
The docs for http::uri::Uri are correct in the description of an Uri:
But the implementation is broken; only URLs are parsed correctly, anything without #[test]
fn should_fail() {
let u : Uri = "mailto:someone@example.com".parse().unwrap();
assert_eq!(u.authority().unwrap().as_str(), "mailto:someone@example.com");
assert_eq!(u.scheme(), None);
} |
|
Actually fixing this is a lot harder that it seems, because of these two very ugly (but valid) edge cases:
|
For context, I'm writing a caldav client. As per the rfc, a user should only need to input an Uri, which can be either The natural choice for me is to use the existing |
Is there any update on this? Username and password are needed |
A function to extract usernames from
Uri
s/Authority
s would be super userful. E.g.:The docs for
http::uri::Uri::authority
mention:However, I can't find any reference to this being deprecated anywhere. rfc6764 is still current and expects this format to be used in the context of caldav and carddav (which is just xml over http). rfc6068 also still uses this, albeit in the context of email.
The text was updated successfully, but these errors were encountered: