(Side note: This was going to be a bug report about the same method accepting noncharacters, but reading the spec again I realize that's actually allowed and is just meant to give a warning?)
While the opaque host parser algorithm is silent on the empty string (thus mapping it to the empty string), the opaque host type itself is specified to be non-empty (the empty host is something else because of course it is).
Due to this, url::Host::parse_opaque("") returning Ok(Domain("")) is... I guess bug compatible with the URL spec? url::Host is clearly not meant to contain only valid host literals (its Domain variant is an unprotected arbitrary string) but this a bit more weird than I think was intended.
I'm really not sure this counts as a bug report (it returns an invalid opaque host by following the spec) but at the very least I'd like its intentionality to be known.
(Side note: This was going to be a bug report about the same method accepting noncharacters, but reading the spec again I realize that's actually allowed and is just meant to give a warning?)
While the opaque host parser algorithm is silent on the empty string (thus mapping it to the empty string), the opaque host type itself is specified to be non-empty (the empty host is something else because of course it is).
Due to this,
url::Host::parse_opaque("")returningOk(Domain(""))is... I guess bug compatible with the URL spec?url::Hostis clearly not meant to contain only valid host literals (its Domain variant is an unprotected arbitrary string) but this a bit more weird than I think was intended.I'm really not sure this counts as a bug report (it returns an invalid opaque host by following the spec) but at the very least I'd like its intentionality to be known.