aio-libs / yarl / 40493646316

98%

push

github

Reject a relative join against an opaque path base in WHATWG mode (#2000)

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

## What do these changes do?

The WHATWG URL Standard resolves only a fragment against a base with an
opaque path (a non-special scheme, no authority and a path not starting
with `/`, such as `sc:sd`, `a:` or `urn:isbn:0451450523`). Any other
reference fails in its no scheme state. In WHATWG mode `URL.join()` now
raises `ValueError` for such a reference without a scheme; `#x` still
gives `sc:sd#x`.

RFC mode keeps merging the paths, and now removes the dot segments of a
merged path without an authority with `remove_dot_segments()` as RFC
3986 section 5.2.4 does, so `../i` against `sc:sd/sd` is `sc:/i` instead
of `sc:i`.

The regenerated conformance report moves 10 rows into "yarl follows each
standard in its mode" (9 from "WHATWG mode differs from WHATWG", 1 from
"Both modes differ from their standard"). The "yarl differs, RFC
3986+3987 and WHATWG agree" section stays empty.

## Are there changes in behavior for the user?

Yes. In the default WHATWG mode, `URL("urn:x").join(URL("y"))` and
similar joins against an opaque path base now raise `ValueError` instead
of returning `urn:y`. In RFC mode, `URL("foo:a/b",
mode="rfc").join(URL("../c", mode="rfc"))` is now `foo:/c`.

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

No. The check runs only for a base without a host, so the join hot path
for hierarchical bases is unchanged.

## Related issue number

N/A

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt`
- [x] Add a new news fragment into the `CHANGES/` folder

Drafted with Claude Code (Claude Opus 5.5); reviewed by @asvetlov.

<details>
<summary>Agent run details (optional, for reviewers)</summary>

Tests: `pytest ./tests ./yarl -n auto`: 3645 passed, 55... (continued)

97 of 194 branches covered (50.0%)

Branch coverage included in aggregate %.

66 of 66 new or added lines in 3 files covered. (100.0%)

11583 of 11733 relevant lines covered (98.72%)

0.99 hits per line