Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hostname false positive #908

Closed
steelbrain opened this issue Jun 1, 2016 · 6 comments
Closed

Hostname false positive #908

steelbrain opened this issue Jun 1, 2016 · 6 comments
Assignees
Labels
non issue Issue is not a problem or requires changes

Comments

@steelbrain
Copy link

Context

  • node version: v6.1.0
  • joi version: v8.1.1
  • environment (node, browser): node
  • used with (hapi, standalone, ...): Not sure, horizon uses this and I am using horizon

More info in the horizon bug, rethinkdb/horizon#545

@Marsup
Copy link
Collaborator

Marsup commented Jun 2, 2016

That would be a wontfix. It's acting according to RFC afaik.

  1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
    to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
    sign (-), and period (.).

@steelbrain
Copy link
Author

Well the ping to that hostname in Linux and OSX works (not tested in Windows), it works when accessed from Node.js net APIs, I think that's because it's allowed

@Marsup
Copy link
Collaborator

Marsup commented Jun 2, 2016

That's a validation of an RFC, if operating systems don't respect that maybe you need to use your own regex.

@steelbrain
Copy link
Author

I suppose you have a point

@augnin
Copy link

augnin commented Jun 2, 2016

there are many similar issues related to docker-compose where people have complained about similar validation failures on other platforms

docker/compose#472
docker/compose#229

FYI docker-compose links containers with an alias <project_name>_<service_name>_<instance_num> and creates entries in container's /etc/hosts file similar to:

172.17.0.3  <service_name> <container_id> <project_name>_<service_name>_<instance_num>
172.17.0.3  <service_name>_<instance_num> <container_id> <project_name>_<service_name>_<instance_num>
172.17.0.3  <project_name>_<service_name>_<instance_num> <container_id> 

in which case you'll be able to connect to your linked service using any of the following host names:

  1. <service_name>
  2. <service_name>_<instance_num>
  3. <project_name>_<service_name>_<instance_num>

Your hostname validation would fail in case you use 2 or 3 in any case. 1 would fail if your service name as defined in docker-compose.yml contains an underscore.

you may want to refer to https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/#updating-the-etc-hosts-file

@steelbrain
Copy link
Author

@sybt I fixed it by specifying hostname in docker-compose instead of letting it automatically choose one

@Marsup Marsup added the non issue Issue is not a problem or requires changes label Jun 3, 2016
@Marsup Marsup self-assigned this Jun 3, 2016
@lock lock bot locked as resolved and limited conversation to collaborators Jan 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
non issue Issue is not a problem or requires changes
Projects
None yet
Development

No branches or pull requests

3 participants