Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
Richard-W opened this issue Jun 21, 2019 · 6 comments · May be fixed by #698
Open

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

Richard-W opened this issue Jun 21, 2019 · 6 comments · May be fixed by #698

Comments

@Richard-W
Copy link

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
Copy link
Collaborator

Probably fine to support. You mind submitting a PR?

@Richard-W
Copy link
Author

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

@bluetech
Copy link

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
Copy link

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

Richard-W added a commit to Richard-W/http that referenced this issue May 16, 2020
@Richard-W
Correctly parse file URIs
bd28b3f 
This changes the URI parser to allow URIs of the forms
* scheme:/absolute/path
* scheme:///absolute/path

It does impact HTTP URI parsing in that HTTP URIs without an authority
part are now allowed.

Fixes issue hyperium#323
@Richard-W Richard-W mentioned this issue May 16, 2020
Open
@shutton
Copy link

shutton commented Aug 5, 2021

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.

@damooo damooo mentioned this issue Feb 11, 2022
Open
@kriswuollett kriswuollett mentioned this issue Jan 30, 2024
Open
@andrewbaxter andrewbaxter mentioned this issue May 9, 2024
Open
@andrewbaxter
Copy link

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).

@andrewbaxter andrewbaxter linked a pull request May 10, 2024 that will close this issue
Open
@RuairidhWilliamson RuairidhWilliamson mentioned this issue Jun 29, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Allow empty authority in absolute URIs andrewbaxter/fork-http
6 participants
@carllerche @shutton @andrewbaxter @bluetech @georgewfraser @Richard-W