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.

Sign up for GitHub

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

Jump to bottom

Re-add support for configuring server.host: "0" #86806

Merged
merged 1 commit into from
Dec 22, 2020
Merged

Re-add support for configuring server.host: "0" #86806

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion src/core/server/http/http_config.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -195,7 +195,13 @@ export class HttpConfig {
rawExternalUrlConfig: ExternalUrlConfig
) {
this.autoListen = rawHttpConfig.autoListen;
this.host = rawHttpConfig.host;
// TODO: Consider dropping support for '0' in v8.0.0. This value is passed
// to hapi, which validates it. Prior to hapi v20, '0' was considered a
// valid host, however the validation logic internally in hapi was
// re-written for v20 and hapi no longer considers '0' a valid host. For
// details, see:
// https:/elastic/kibana/issues/86716#issuecomment-749623781
this.host = rawHttpConfig.host === '0' ? '0.0.0.0' : rawHttpConfig.host;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@watson We should probably follow up in all the places where we use this for testing, replace it with 0.0.0.0 and then remove it from 0?

Thanks for the fix BTW

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's best to support this in 7.x and then wait till 8.0.0 to remove it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. But the 8.0.0 removal could already happen now. An email could be sent to the teams to give a heads up that it will be removed in x weeks with the fix that needs to happen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine with me 😃 I just wasn't sure what our policy on diverging the branches was. I've heard some say that we want to keep master and 7.x in sync as much as possible to ease backporting. I presume that would mean that we hold off diverging the branches until closer to the 8.0.0 release (hence why we have the big todo-list of things we want to break).

On the other and, it's easier to get it in now when it's all fresh in our heads. I'm personally leaning towards the latter, so I'll create a PR to remove this in master and then people can object if they want in the PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No strong opinion, I let the KB team comment ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've created #87114 - You mentioned that the docs use 0 as the hostname. Where is that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did mention docs? :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strike that... It was @graphaelli

this.port = rawHttpConfig.port;
this.cors = rawHttpConfig.cors;
this.customResponseHeaders = Object.entries(rawHttpConfig.customResponseHeaders ?? {}).reduce(
Expand Down