Spec non-compliance inconsistency in URI parsing

[Insomniak47]

Hey all,

Back again, it seems like the following lines from /src/uri/mod.rs are non-spec compliant:

//855 in my branch, around there in master. 

    if scheme.is_none() {
        if authority_end != s.len() {
            return Err(ErrorKind::InvalidFormat.into());
        }

        let authority = Authority {
            data: unsafe { ByteStr::from_utf8_unchecked(s) },
        };

        return Ok(Uri {
            scheme: scheme.into(),
            authority: authority,
            path_and_query: PathAndQuery::empty(),
        });
    }

which makes sense because the spec isn't necessarily ergonomic in this case. It seems though if you're going to deviate from spec it should be a bit more consistent.

the table at:
https://tools.ietf.org/html/rfc3986#section-5.4.1

Indicates that with no scheme this would really be a relative path. Given that basically nobody would interpret it this way I can understand the desire to handle it as an authority though I don't see why you'd require that is exclusively an authority.

in "test_authority_uri_parts_round_trip" hyper.rs is parsed and round tripped. It seems odd to return an error on parsing if instead it was hyper.rs/somethingelse. I can put in the fix I just want to make sure everybody is on the same page re: ergonomics/implementation.

[seanmonstar]

Possibly some confusion can come from the name, Uri. The true role of this type is request-target from RFC7230. So, it's legal to request in authority-form, like CONNECT hyper.rs HTTP/1.1. However, CONNECT hyper.rs/guides would be wrong.

That's the role this type originally had in hyper, before it was extract and named Uri...

[Insomniak47]

That makes sense given the context though I think discrepancies are going to keep coming up between the definitions. In the same way "/mySpecialPath" wouldn't meet the reqs of RFC7230 SS 5.3 but that parses fine. If the parsing is going to impose restrictions like that it would probably make sense to be consistent.

So I guess the questions I have are:

• Is this something you have a position on WRT standardizing?
• Is the goal to be RFC7230 compliant on request-target?
• Is there anything that relies on this behaviour specifically?
• Do you want to support this behaviour?

[seanmonstar]

In the same way "/mySpecialPath" wouldn't meet the reqs of RFC7230 SS 5.3

Hm? Is there something non-obvious here? It looks like that matches origin-form to me.

However, I don't think we need to strictly enforce RFC 7230 (we've already loosen up some of the parsing rules to match the URL spec WRT what characters are allowed). It's still up to a server to handle cases correctly (since something like CONNECT /foo HTTP/1.1 would not fail parsing without context, but should still be a a 400 Bad Request once the server adds context.

[Insomniak47]

Oh sorry, you're right re:that one. I'll close this