aio-libs / yarl / 40513624609

98%

push

github

Keep an IPv6 address as written in RFC 3986 mode (#2001)

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

## What do these changes do?

RFC 3986 mode now keeps an IPv6 address in the host as written, only
lowercased per section 6.2.2.1, instead of compressing it:
`http://[1:0::]` and `http://[::127.0.0.1]` stay as they are. RFC 3986
section 6.2.2 does not compress an IP-literal, and the strict oracle in
`tools/conformance/` agrees. WHATWG mode still writes the compressed
form, as the WHATWG URL Standard does, and moving a URL to WHATWG mode
compresses the address.

`_encode_host()` returns the written form as the encoded host and the
compressed form as the WHATWG host when they differ, so the existing
WHATWG branches in the parser, `URL.build()`, `with_host()` and the mode
change pick the compressed one without new code. A zone identifier is
handled as before.

In RFC mode `[1:0::]` and `[1::]` are now different hosts, so those URLs
no longer compare equal; section 6.2.2 does not require them to, and the
oracle keeps them apart. WHATWG mode still compares them equal.

## Are there changes in behavior for the user?

Yes, in RFC 3986 mode only: an IPv6 host that is not written in
compressed form keeps its spelling in `str()`, `host` and `raw_host`,
and such URLs no longer compare equal to the compressed spelling. In the
conformance report the five RFC mode "IP-literal host" rows move from
*RFC mode differs from RFC 3986+3987, WHATWG mode follows WHATWG* to
*yarl follows each standard in its mode* (348 to 353 follow, 17 to 12
RFC mode gaps, forbidden section still empty).

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

No. The change is a few lines in the IPv6 branch of the cached
`_encode_host()`; the path for ordinary hosts is untouched.

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

97 of 194 branches covered (50.0%)

Branch coverage included in aggregate %.

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

11610 of 11760 relevant lines covered (98.72%)

0.99 hits per line