aio-libs / yarl / 36869408180

98%

push

github

Resolve references with a scheme strictly in RFC 3986 mode (#1955)

<!-- Thank you for your contribution! -->

## What do these changes do?

`URL.join()` with a base in RFC 3986 mode now behaves as the strict
parser of RFC 3986 section 5.2.2: a reference with a scheme is used as
is, also when the base has the same scheme. `file:test` against
`file:///tmp/mock/path` is `file:test`, and `http:g` against an http
base is `http:g`. WHATWG mode keeps resolving such a reference as a
relative one, as the WHATWG URL Standard requires.

RFC 3986 mode also removes dot segments from the path of a URL that has
a scheme but no authority, as section 5.2.2 does for any reference with
a scheme: `file:..` and `file:.` are `file:`, `file:.//p` is `file:/p`.
`URL.build()`, `with_path()`, `joinpath()` and `/` do the same, so a URL
they build does not change when parsed again. The removal follows
section 5.2.4 step by step in a new `remove_dot_segments()`; the
existing `normalize_path()` drops the leading slash that the algorithm
leaves when a `..` climbs above the first segment of a rootless path
(`urn:a/../b` is `urn:/b`, not `urn:b`). Paths with an authority keep
using `normalize_path()`, where both agree.

This is the first of three changes for the file scheme rows of the
conformance report. It moves 16 rows (10 file, 6 http) from "RFC mode
differs from RFC 3986+3987, WHATWG mode follows WHATWG" to "yarl follows
each standard in its mode"; no other row changes section.

## Are there changes in behavior for the user?

Yes, in RFC 3986 mode only. A base in RFC mode no longer resolves a
same-scheme reference like `http:g` against itself, and paths of scheme
URLs without an authority lose their dot segments, whether parsed or
built. WHATWG mode and relative references are unchanged.

## Is it a substantial burden for the maintainers to support this?

No. Two small branches on the URL mode; the WHATWG paths do not take
them.

## Related issue number

N/A

## Checklist

- [x... (continued)

97 of 194 branches covered (50.0%)

Branch coverage included in aggregate %.

104 of 104 new or added lines in 4 files covered. (100.0%)

9768 of 9899 relevant lines covered (98.68%)

0.99 hits per line