Re: [whatwg/url] Proposal: URL.parseIPv4() URL.parseIPv6() (Issue #696)

I've been adding host-parsing APIs to my Swift library recently to handle these kinds of use-cases. There really are [a lot of edge-cases](https://github.com/karwa/swift-url/blob/0d5e2b25046303ee15060b3b2627f0fc9e8c60fc/Tests/WebURLTests/HostTests.swift#L382) to go through, so it truly does need the whole host parser every time. For example, not only do IPv4 addresses get parsed after IDNA, that also happens after percent-decoding, so if you want truly URL-compatible parsing, it needs to also return that `"0x%F0%9D%9F%95f.1"` is an IPv4 address (`127.0.0.1`):

```
"0x%F0%9D%9F%95f.1" -> (percent-decoding) -> "0x𝟕f.1" -> (IDNA) -> "0.7f.1" -> (IPv4) -> 127.0.0.1
```

It's such a long distance from input to output that IMO it's not worth providing users with anything other than the complete, parsed result. I'm not sure about how allocations work in JS specifically, but I doubt there would be any performance gain by doing anything else, especially considering that domain-to-ASCII in particular is not trivial and often needs to allocate. I think performance wins are likely going to be found at the application level by storing parsed results so you don't need to parse them again.

Also - if the API told people that `"0x%F0%9D%9F%95f.1"` is an IPv4 address (which it is in URLs), what would they do with that information? Probably no other parser they can find will actually turn that string in to an IPv4 address, so we might as well give them the complete result that the URL host parser interpreted.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/696#issuecomment-1172812978

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/696/1172812978@github.com>