Allow empty authority in absolute URIs

[andrewbaxter]

Fixes #323

This removes the restriction preventing empty authority in URIs. The canonical example of this is file:/// which has a zero-length authority. While these may not be relevant for a web server, there are many domains that need these sorts of alternative URIs (for example Webview-based software which reads local resources).

https://datatracker.ietf.org/doc/html/rfc3986 pretty clearly describes the authority as optional in all situations AFAICT, but it mentions that schema-specific restrictions may be in place.

This is the case for HTTP addresses, described in https://www.rfc-editor.org/rfc/rfc9110.html#name-identifiers-in-http

The origin server for an "https" URI is identified by the authority component
...
A sender MUST NOT generate an "https" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.

It's possible that some users of this library in a strictly-http context may be relying on this checking the validity of the HTTP identifier for them. I'm not sure how to handle this, maybe with a version bump? The legacy behavior could be considered a bug though.

Eventually a separate HttpUri type or something that performs the additional checks when constructed might be useful.

[seanmonstar]

I'm not immediately against this change, but I am a bit skeptical. Notably, this crate is purposefully meant for the HTTP usecase, not a general URL parser. (HttpUri seems like it already exists, http::Uri).

[seanmonstar]

Also, recently opened: #696.

[andrewbaxter]

FWIW I opened this because I thought @carllerche had given the okay for it in #323 , but you're right, this is http::Uri after all.

Despite varied requirements, the rust ecosystem still hasn't seen a second Uri crate and this is used pretty widely - I'm not sure the ecosystem could support another implementation of a Uri crate. Is there a way some of the core functionality could be shared with another crate with a more permissive frontend in such a way that the types would be trivially convertible?

On the other hand, I don't think any software relies on this check for correct operation... I think this error is at most used to detect user mistakes early. And in that case, I think other code that consumes Uri probably already performs such a check - for instance, "".to_socket_addrs().unwrap() returns Error { kind: InvalidInput, message: "invalid socket address" } which conveys more or less the same information. From a user perspective you'd troubleshoot "" the same way you'd troubleshoot any other incorrect host name.