You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The comparison traits are implemented for http::uri::Authority by case-insensitively comparing the underlying authority string. This works fine if the authority component only consists of the host subcomponent (and optionally the port subcomponent), which is case-insensitive according to RFC 3986 Section 6.2.2.1.
However, the authority component may also contain a (deprecated according to RFC 9110 Section 4.2.4.) userinfo subcomponent, which is not specified to be case-insensitive and thus should be compared case-sensitively. In particular, the following test should pass:
use http::uri::Authority;#[test]fnuserinfo_eq_case_sensitive(){assert_ne!(Authority::from_static("alice:[email protected]"),Authority::from_static("Alice:[email protected]"));}
But this fails with the current implementation.
Is the behavior intentional? I understand that complicating the implementation for the deprecated subcomponent might not be desirable. But I think this should at least be documented if it's intentional.
The text was updated successfully, but these errors were encountered:
The comparison traits are implemented for
http::uri::Authority
by case-insensitively comparing the underlying authority string. This works fine if the authority component only consists of the host subcomponent (and optionally the port subcomponent), which is case-insensitive according to RFC 3986 Section 6.2.2.1.However, the authority component may also contain a (deprecated according to RFC 9110 Section 4.2.4.) userinfo subcomponent, which is not specified to be case-insensitive and thus should be compared case-sensitively. In particular, the following test should pass:
But this fails with the current implementation.
Is the behavior intentional? I understand that complicating the implementation for the deprecated subcomponent might not be desirable. But I think this should at least be documented if it's intentional.
The text was updated successfully, but these errors were encountered: