aio-libs / yarl / 36529445476

98%

push

github

Measure both modes in the conformance report (#1938)

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

## What do these changes do?

`tools/conformance/compare.py` now runs every WPT case through yarl
twice, in the default WHATWG mode and in RFC 3986 mode, and compares
each mode with its own standard. The report gets a new section, "yarl
follows each standard in its mode", for cases where the standards differ
and WHATWG mode gives the WHATWG result while RFC mode gives the RFC
3986 one. The other sections are replaced by "WHATWG mode differs from
WHATWG", "RFC mode differs from RFC 3986" and "Both modes differ from
their standard". AGENTS.md now states the goal: every case either agrees
everywhere or lands in the new section.

Measuring RFC mode surfaced two cases where both standards fail and RFC
mode accepted the input. RFC mode now rejects both. For `sc://te@s:t@/`,
an authority with more than one `@` is now rejected in RFC mode, because
RFC 3986 userinfo cannot contain `@`. For `http://💩.123/`, a non-ASCII
host that IDNA2008 (RFC 5891, which RFC 3987 now points to) cannot
encode is rejected in RFC mode, instead of using the IDNA2003 fallback.
WHATWG mode keeps both behaviours. "yarl differs, RFC 3986 and WHATWG
agree" is back to the single deferred `http://[::%31]` row.

Current counts: 450 agree, 28 follow each standard in their mode, 1 in
the forbidden section, 202 with WHATWG mode off, 116 with RFC mode off,
99 with both off.

## Are there changes in behavior for the user?

Yes, in RFC mode only: `URL('http://a@b@example.com/', mode='rfc')` and
`URL('http://💩/', mode='rfc')` raise `ValueError`. The same checks apply
to `URL.build()` and `with_host()` in RFC mode.

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

No.

## Related issue number

Follow-up to #1923 and #1931.

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

96 of 192 branches covered (50.0%)

Branch coverage included in aggregate %.

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

8827 of 8944 relevant lines covered (98.69%)

0.99 hits per line