aio-libs / yarl / 36703904608

98%

push

github

Read a backslash as a slash in special URLs in WHATWG mode (#1943)

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

## What do these changes do?

In the default WHATWG mode, a backslash before the query is now read as
a slash in URLs of the special schemes (`http`, `https`, `ws`, `wss`,
`ftp`, `file`), as the WHATWG URL Standard does:
`http://example.com\path` becomes `http://example.com/path` instead of
raising. A relative reference keeps the backslash until `join()` sees a
special base, so `URL("http://example.org/a").join(URL("\\x"))` is
`http://example.org/x`, while a non-special base keeps its host (`\/a`
against `foo://foo/a` does not become `foo://a`). The converted
reference shares the cache entry and pickle slot of the `http:g` join
path from #1937, and survives `with_query()`, `with_fragment()` and the
other query methods, as #1948 makes the `http:g` path do. Non-special
schemes, the query and the fragment keep the backslash percent-encoded,
as before. `human_repr()` now writes `%5C` in the path so its output
still parses back to the same URL.

RFC 3986 has no backslash in its grammar, so RFC 3986 mode now rejects a
URL string that contains one. Built components (`URL.build(path=...)`,
`with_path()` and so on) and `encoded=True` are unchanged.

The conformance report moves 21 rows into "yarl follows each standard in
its mode" (166 to 187), and "Both modes differ" drops from 98 to 53. The
"yarl differs, RFC 3986 and WHATWG agree" section is unchanged.

## Are there changes in behavior for the user?

Yes. In WHATWG mode, `\` in the authority or path of a special URL, or
of a relative reference joined with one, is a `/`; before, it raised in
the authority and was percent-encoded in the path. RFC 3986 mode raises
`ValueError` on any backslash in a parsed URL string.

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

No. It is one string pass in the unencoded parser, and it only runs when
the input contains a backslash.

## Related i... (continued)

97 of 194 branches covered (50.0%)

Branch coverage included in aggregate %.

202 of 205 new or added lines in 5 files covered. (98.54%)

9361 of 9488 relevant lines covered (98.66%)

0.99 hits per line