Panic on resolving ./..//bar against scheme:foo1/foo2

[lo48576]

use uriparse::{URI, URIReference};

fn main() {
    let base = URI::try_from("scheme:foo1/foo2").unwrap();
    let reference = URIReference::try_from("./..//bar").unwrap();
    let target = base.resolve(&reference);
    println!("target = {:?}", target);
}

$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/uritest`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: AbsolutePathStartsWithTwoSlashes', /home/lo48576/.cargo/registry/src/github.com-1ecc6299db9ec823/uriparse-0.6.3/src/uri.rs:702:25
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::result::unwrap_failed
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1616:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1298:23
   4: uriparse::uri::URI::resolve
             at /home/lo48576/.cargo/registry/src/github.com-1ecc6299db9ec823/uriparse-0.6.3/src/uri.rs:702:9
   5: uritest::main
             at ./src/main.rs:6:18
   6: core::ops::function::FnOnce::call_once
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I'm implementing another crate (iri-string) for RFC 3986/3987, and fonud this problematic input (See lo48576/iri-string#8).
I think this should not panic, but I'm not sure how this should be handled.
How do you think?

(I suspect it is a defect of RFC 3986 that the results or examples for this kind of cases are not clearly provided...)

[sgodwincs]

It does seem to be an oversight of the RFC. I'm not sure how I feel about making normalization fallible though, since it seems very reasonable that if you have a valid URI A, it should still be valid after normalization. I'm probably leaning towards removing one of the double slashes if it occurs after normalization.

EDIT: This was mainly referring to your issue where removing dot segments can inadvertently create an authority out of no where which would suggest that both normalization and reference resolving are problematic.

[lo48576]

Yes, reference resolution and normalization are both affected.

It seems that WHATWG's spec for URL avoids this by appending /. prefix to the path (on serialization, not on resolution or normalization) when this problem happens.
(whatwg/url#505, jsdom/whatwg-url#148).
In my crate I'm implementing RFC 3986 and RFC 3987 so I made resolutions and conversions fallible, but appending /. seems to be a practical solution in most contexts if you don't want to allow them to fail .