Open SapphicCode opened 5 years ago
As per https://tools.ietf.org/html/rfc3986#section-3.2.2 URIs dont allow _
as a character and therefore that is invalid. See also https://tools.ietf.org/html/rfc1034#section-3.5.
Point taken, but a hostname:port
combination is not a URI and should not be bound by the same restrictions, in my opinion. (Additionally, the DNS specification does allow for underscores in domain names, and thus host names.)
Anyhow, the question of using underscores in hostnames was not a topic I wanted to put up for debate, as that is something best relegated to the designers of tools such as Docker and Docker Compose. My request was merely that it'd be supported, as most things do.
It seems using java.net.URL instead should fix the issue: https://bugs.openjdk.java.net/browse/JDK-8170265
The fix is trivial, but bad as it means faking the URL protocol as something has a handler for like HTTP.
(Additionally, the DNS specification does allow for underscores in domain names, and thus host names.)
No it doesn't, only on certain record types like SRV. Wikipedia agrees on this point: https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames
Wow this issue has been asked since almost 3 years ago, so is there a chance this issue will be fixed in the future? since it's useful for those who hosting their server using docker compose (docker networks).
Wow this issue has been asked since almost 3 years ago, so is there a chance this issue will be fixed in the future? since it's useful for those who hosting their server using docker compose (docker networks).
cant you set it up without underscores?
For example, If I'm using docker-compose with --scale command, it's gonna automatic generate "_1", "_2" prefix on running container, that's the problem.
Of course I could use host network instead of bridging, but it also losing the benefits of using bridge net (that I don't need to care about ports)
In a nutshell,
java.net.URI
does not support underscores in hostnames. However in the Docker world, underscores in container hostnames are quite frequent, and as a result this exception gets raised.