-
Notifications
You must be signed in to change notification settings - Fork 8k
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
[http] explicitly create the server listener #183591
[http] explicitly create the server listener #183591
Conversation
/ci |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self-review
config: IHttpConfig, | ||
options: GetServerListenerOptions = {} | ||
): ServerListener { | ||
return configureHttp1Listener(config, options); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where we will properly branch to configure an http2 listener instead.
}); | ||
|
||
return server; | ||
export function createServer(serverOptions: ServerOptions) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The root createServer
function is even simplified, because the options returned by createServerOptions
now contain everything.
Note: I did not delete the function because it still provides a good isolation and separation of concern.
// manually configuring the listener | ||
listener: getServerListener(config, { configureTLS }), | ||
// must set to true when manually passing a TLS listener, false otherwise | ||
tls: configureTLS && config.ssl.enabled, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the concrete change of configuration introduced by this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not in the scope of this PR, but I'm wondering why we have a configureTLS
parameter. We don't seem to have any use case where we set a false
value for it.
Perhaps I missed something, but I have a feeling that it should either be removed, or surfaced and put together with the rest of IHttpConfig
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do use it (once), for the redirect server:
kibana/packages/core/http/core-http-server-internal/src/https_redirect_server.ts
Lines 31 to 37 in 0d53e16
// Redirect server is configured in the same way as any other HTTP server | |
// within the platform with the only exception that it should always be a | |
// plain HTTP server, so we just ignore `tls` part of options. | |
this.server = createServer({ | |
...getServerOptions(config, { configureTLS: false }), | |
port: config.ssl.redirectHttpFromPort, | |
}); |
/** | ||
* Composite type of all possible kind of Listener types. | ||
* | ||
* Unfortunately, there's no real common interface between all those concrete classes, | ||
* as `net.Server` and `tls.Server` don't list all the APIs we're using (such as event binding) | ||
*/ | ||
export type ServerListener = HttpServer | HttpsServer; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(just preparing for the next step by introducing a proper listener type)
/ci |
/ci |
…nge-listener-config
/ci |
Pinging @elastic/kibana-core (Team:Core) |
keepAliveTimeout: config.keepaliveTimeout, | ||
}); | ||
|
||
listener.setTimeout(config.socketTimeout); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We used to define a .on('timeout', handler)
too.
Is this no longer needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Na, good catch, I totally missed to re-add the
server.listener.on('timeout', (socket) => {
socket.destroy();
});
TBH I'm not sure this is really useful (given I assume sockets will be destroyed on timeout anyway), but let's the purpose of the PR is not to test that, so I will add it back. Thanks!
createServer, | ||
IHttpConfig, | ||
} from '@kbn/server-http-tools'; | ||
import { getServerOptions, createServer, IHttpConfig } from '@kbn/server-http-tools'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT IHttpConfig
can be imported as a type.
import { getServerListener } from './get_listener'; | ||
|
||
const createConfig = ( | ||
parts: Partial<Omit<IHttpConfig, 'ssl'>> & { ssl?: Partial<IHttpConfig['ssl']> } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tried to simplify this locally, and TS does not complain when doing:
parts: Partial<IHttpConfig>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure I had to adapt because partial !== deep partial, and I was using deep partials for config.ssl
, but I will check again
EDIT: Nope, you're right. I guess I changed how I manipulate the config creation at some point in the test
@@ -20,7 +21,9 @@ jest.mock('fs', () => { | |||
}; | |||
}); | |||
|
|||
const createConfig = (parts: Partial<IHttpConfig>): IHttpConfig => ({ | |||
const createConfig = ( | |||
parts: Partial<Omit<IHttpConfig, 'ssl'>> & { ssl?: Partial<IHttpConfig['ssl']> } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM! Just a few minor doubts / suggestions, and one question around the on('timeout', handler)
.
…nge-listener-config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚀
…nge-listener-config
…nge-listener-config
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
Summary
Related to #7104
Adapted from #183465
For
http2
support, we will have to change the way we configure the HAPI server to manually provide the listener instead of passing down the options for HAPI to create it.This PR prepares that work, by creating the
http
orhttps
(tls
) listener and passing it when creating the HAPI server instead of just passing thetls
options.Note: no integration tests were added, because we already have the right coverage for both tls and non-tls mode, so any change of behavior introduced by the PR should be detectable by them.