Cannot parse URI without authority component

[maxlambrecht]

Trying to parse an URI like unix:///tmp/agent.sock or unix:/tmp/agent.sock, that has a schema and not an authority, produces an Error InvalidaUri(InvalidFormat).

There is no restriction defined in the URI standard that would make these URIs invalid.

The use-case I have is connecting to a SPIFFE Workload Endpoint: https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Workload_Endpoint.md#4-locating-the-endpoint.

[adamreichold]

I think I am hitting a similar issue where a location header that contains a path is parsed as an authority

[tests/path.rs:5] "forum".parse::<Uri>().unwrap().into_parts() = Parts {
    scheme: None,
    authority: Some(
        forum,
    ),
    path_and_query: None,
    _priv: (),
}

or not at all if it has a trailing slash

[tests/path.rs:5] "forum/".parse::<Uri>() = Err(
    InvalidUri(
        InvalidFormat,
    ),
)

[nox]

@adamreichold What you pasted is orthogonal to the ticket and AFAIK both your pastes aren't bugs.

[adamreichold]

@nox Thank you for looking into this! Can you go into slightly more detail why both instances are valid behaviour so that I can better understand how to work around this? Thanks!

[nox]

The Uri type in that crate was mostly designed to represent a HTTP request target as defined in https://httpwg.org/specs/rfc7230.html#request-target.

• origin-form is more or less an absolute path, that starts with /.
• absolute-form is a complete URL in all its glory, with the scheme etc.
• authority-form is well, an authority, that is, the localhost part in http://localhost/, that's your first example.
• asterisk-form is just *, used for OPTIONS requests for example.

So this covers the first example forum, which as you've stated is successfully.

If you read the rules for those 4 cases, you'll notice that the only forms that can accept a / are origin-form and absolute-form, and that forum/ fits neither, hence the error you've encountered.

[adamreichold]

The Uri type in that crate was mostly designed to represent a HTTP request target

So basically, this boils down to Uri handling request-target but not URI-reference in the parlance of RFC 7230. 🤔

[nox]

Yes, cause it represents an URI in the context of a HTTP request/response cycle, where GET forum HTTP/1.0 is not valid.