Hapi: Hostname semantics

Created on 3 Nov 2017  ·  10Comments  ·  Source: hapijs/hapi

First of all, I want to say that hapi 17 looks awesome and I am very excited about it. Great work and thank you. ❤️

That said, I have what is obviously the most least important request you have received in the lifetime of the framework. But one that would make me happy.

That is, to align the server options with the standardized semantics of host vs hostname.

As an example, I would like to be able to:

const { URL } = require('url');
const hapi = require('hapi');
const { host, hostname, port } = new URL('http://localhost:3000');

const server = new hapi.Server({ host });
// ... or ...
const server = new hapi.Server({ hostname, port });

hapi already seems to _sort of_ know the difference...

new hapi.Server({ host });
Error: Invalid server options {
  "routes": {},
  "host" [1]: "localhost:3000"
}

[1] "host" must be a valid hostname

hapi's host is really a hostname and is incompatible with perfectly valid hosts such as localhost:3000.

If you don't want to deal with this, I understand. I think Node is the real culprit here, so I filed https://github.com/nodejs/node/issues/16712. It would still be nice if hapi fixed it separately, though. And thankfully, it would be backwards compatible.

feature

Most helpful comment

hosts ... must have a : separator

No, not really, that is only true if a port is present in the host. But ports are optional for a host. If a port is not present, then : should be disallowed and a default port is usually assumed (the same way that the port property may have a default). The URL spec defines a default port for protocols such as HTTP and HTTPS, WebSockets, and others, but I'm not suggesting changing hapi's defaults.

| Value | Valid Host | Valid Hostname |
|--|--|--|
| localhost | ✔️ | ✔️ |
| localhost:3000 | ✔️ | ❌ |
| localhost: | ❌ | ❌ |

The above table is based on the parsing behavior of the APIs mentuoned in https://github.com/nodejs/node/issues/16712.

All 10 comments

If someone adds Joi.string().host() support and then submits a PR that changes the config rules + parses the host and grabs a port if present + asserts on port in both port and host, then I'll accept it.

I'm new here but I would like to help with this, can you give me some pointer on how to approach this?

@ankitsinghaniyaz Step one is to add host validation support to joi.

I'm just summarizing my understand here the real difference between host and hostname for people who don't know and for my clarity.

localhost:3000 is a host
localhost is the hostname

If a port is not defined both are same. So the validation for host will look something like this.

  • must have a : separator
  • the first part can be a string/number, can have a max length validation
  • the second part should be a number must be in the range of 1 to 65535

@hueniverse please let me know if I am missing anything, I'll go and add this rules to Joi. :)

Update

It seems the hostname validator is already present, so it's even easier. It is just a matter of validating that the first part is hostname and the last part follows the rule described in 3rd point above.

hosts ... must have a : separator

No, not really, that is only true if a port is present in the host. But ports are optional for a host. If a port is not present, then : should be disallowed and a default port is usually assumed (the same way that the port property may have a default). The URL spec defines a default port for protocols such as HTTP and HTTPS, WebSockets, and others, but I'm not suggesting changing hapi's defaults.

| Value | Valid Host | Valid Hostname |
|--|--|--|
| localhost | ✔️ | ✔️ |
| localhost:3000 | ✔️ | ❌ |
| localhost: | ❌ | ❌ |

The above table is based on the parsing behavior of the APIs mentuoned in https://github.com/nodejs/node/issues/16712.

Does the parser need to support IPv6?

@dsfields whatever joi supports today.

@sholladay in regard to:
https://github.com/hapijs/joi/pull/1356#issuecomment-344292124

While working on the Joi.string.host() validation PR there was guidance and reference that is in conflict with the table you provided, specifically the second row localhost:8080 being a valid host :
https://github.com/hapijs/joi/pull/1356


@DavidTPate referenced RFC 3986:
https://github.com/hapijs/joi/pull/1356#issuecomment-344292124

The host subcomponent of authority is identified by an IP literal
encapsulated within square brackets, an IPv4 address in dotted-
decimal form, or a registered name.

This would not include the Port or Userinfo sections.


@hueniverse also provided feedback and guidance and stated the following:
https://github.com/hapijs/joi/pull/1356#issuecomment-344348986
Host is just the IP address or dns name. No username, password, or port.


The Implementation and PR of Joi.string.host() followed those two comments as guidance.
I want you to be aware of this and if you would like to discuss further, be provided the PR to discuss.
🤜 🤛

As is, I won't personally be able to benefit from the updated joi if it doesn't accept localhost:8080 as a valid host. I replied about that in the PR. joi's interpretation of hostname is already perfect as far as I am concerned, but for some reason hapi incorrectly calls it a host in its options object.

All I want is for one of the following to work. Currently, neither does.

  1. Passing a host

    ```js
    const { host } = new URL('http://localhost:8080');
    const server = new hapi.Server({ host });
    ```
    
  2. Passing a hostname and port separately

    ```js
    const { hostname, port } = new URL('http://localhost:8080');
    const server = new hapi.Server({ hostname, port });
    ```
    

I'm closing this due to lack of progress. Seems like everyone who had any interest in this just stopped paying attention. If at some point someone decides to finish the joi work, please ping me and I'll reopen.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hueniverse picture hueniverse  ·  4Comments

midknight41 picture midknight41  ·  4Comments

jeffbski picture jeffbski  ·  5Comments

leore picture leore  ·  4Comments

DrMabuse23 picture DrMabuse23  ·  5Comments