aio-libs / yarl / 36461803082

98%

push

github

Reject special-scheme hosts that end in a number after a name (#1933)

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

## What do these changes do?

For the special schemes (`http`, `https`, `ws`, `wss`, `ftp`, `file`),
the WHATWG URL Standard runs a host whose last label is a number
(`foo.123`, `💩.123`, `example.0x1f`) through its IPv4 parser, which
fails when another label is not a number. yarl accepted such hosts as a
reg-name. In the default WHATWG mode they are now rejected with
`ValueError` by `URL()`, `URL.build()` (both `host=` and `authority=`)
and `with_host()`, and when `with_scheme()`, `join()` with a `//host`
reference or `URL(url, mode="whatwg")` move such a host into a
special-scheme WHATWG URL; `mode="rfc"` keeps accepting them, since RFC
3986 allows them as a reg-name. Percent-encoded hosts are left alone:
yarl does not decode hosts, so it cannot tell which labels WHATWG would
see.

Hosts made only of numbers, such as `1.2.3`, `0x7f.1`, `256.1.1.1` or
the 50-digit host aiohttp uses in its tests, keep their current
behaviour: WHATWG would reinterpret or reject some of them, but changing
that is a separate decision and would break aiohttp's test suite.

## Are there changes in behavior for the user?

Yes, hence the `breaking` fragment: `URL("http://foo.123/")` raises in
the default mode. Other schemes and RFC mode are unchanged.

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

No. The "ends in a number after a name" flag is computed inside the
cached `_encode_host()`, which now returns it next to the encoded host,
so a cached build or `with_host()` only unpacks the pair and tests the
flag.

## Related issue number

N/A; found by the conformance report in #1923.

## 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/`... (continued)

96 of 192 branches covered (50.0%)

Branch coverage included in aggregate %.

122 of 122 new or added lines in 2 files covered. (100.0%)

8688 of 8805 relevant lines covered (98.67%)

0.99 hits per line