parse::<Uri> fails to parse uris with triple slash after scheme

[richard-w]

URIs that reference resources on a local filesystem often use URIs of the format <scheme>://<path_to_file>. If the path is absolute that leads to URIs with 3 slashes after the scheme like unix:///var/run/socket.sock

The following expression panics with InvalidUri(InvalidFormat):

"unix:///path/to/foo.sock".parse::<Uri>().unwrap();

while a similar expression using a relative file path like unix://relative/path/to.sock works just fine.

While I understand that the http crate does not aim to provide a completely compliant URI parser I still think this should be fixed here because:

• There are http services that do listen on unix sockets (docker for example)
• Allowing relative file and unix URIs while not allowing absolute ones is inconsistent

[carllerche]

Probably fine to support. You mind submitting a PR?

[richard-w]

I do not mind at all but I am a little short on time right now so it may take a while.

[bluetech]

As far as I understand, this is not strictly speaking a valid HTTP request target (you can start tracing from here).

As I understand it, the correct way to write it is unix:/path/to/foo.sock. Unfortunately, http also rejects that, which does seem like a bug.

[georgewfraser]

According to Wikipedia, triple-slash and single-slash are both correct, double-slash is common but wrong: https://en.wikipedia.org/wiki/File_URI_scheme

[shutton]

I think the issue here is that this crate can only talk about URLs that are expected to eventually speak HTTP. The lack of unix:/// is certainly a deficit, but I think a better option would be to reference the url crate, which is generic for all URLs, and then provide a function that indicates whether the specified URL is network-oriented. E.g., a unix:/// endpoint might speak HTTP, or it might just be a file (which isn't obvious until something tries to connect to it). Whereas file:/// is absolutely not a network endpoint.

Just thinking out loud.

[andrewbaxter]

The http crate is used pretty widely, for a variety of situations where pseudo-HTTP are more common, for example in webview which might reasonably be loading local-filesystem resources (and in fact the webview itself has no issues with the file url).