What do these changes do?

TCPConnector._resolve_host already rejects legacy numeric IPv4 aliases (2130706433, 017700000001, 127.1) so they cannot be resolved past a connector-level host policy that only inspects the raw host string. That rejection is gated on is_ip_address(host), whose heuristic is ":" in host or host.replace(".", "").isdigit(), so it only recognises the decimal-dotted forms. Hexadecimal literals like 0x7f000001 and 0x7f.0.0.1 are not seen as IPs at all, so they skip the is_canonical_ipv4_address guard and go straight to the resolver, where getaddrinfo/inet_aton maps them onto 127.0.0.1.

This adds a small is_ipv4_literal helper (backed by socket.inet_aton, so it recognises every form the resolver accepts) and widens the connector guard to use it, closing the hex gap while leaving canonical addresses and real hostnames untouched.

Are there changes in behavior for the user?

Only for the bypass case. Canonical dotted-quad IPs still short-circuit the resolver as before, and real hostnames still resolve normally. A hex/legacy numeric literal that is not canonical now raises InvalidUrlClientError, matching what already happens for the decimal and octal forms.

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

No. It reuses the existing guard and helper next to is_canonical_ipv4_address, and the regression sits in the test that already covers the decimal/octal/short aliases.

Related issue number

None.

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes -- N/A, the helper is internal and there is no public API change
• If you provide code modification, please add yourself to CONTRIBUTORS.txt -- already listed
• Add a new news fragment into the CHANGES/ folder