-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[logging] Downgrade hapi connection errors when connecting with the w… #11209
Conversation
ccf058a
to
04b0d21
Compare
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.
If the answer to my question is "yes, that's our only option" then this LGTM
} | ||
|
||
downgradeIfHTTPSWhenHTTP(event) { | ||
return downgradeIfErrorMessage('Parse Error', event); |
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.
Is error message matching our only option here? Parse Error
is pretty vague isn't it? I guess we're still limiting it by the tag list, but I'd really like to use a value that's intended for machines (like errno
) rather than one that's intended for humans (and much more likely to change/conflict)
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.
Good point, I went straight for text because there was no errno. But there is a code for Parse Error sot hat looks like it's the way to go:
{
event: 'log',
timestamp: 1492194353021,
tags: ['connection', 'client', 'error'],
data: {
Error: Parse Error at Error(native) bytesParsed: 0,
code: 'HPE_INVALID_METHOD'
},
pid: 73405
}
For the http when https case there isn't more:
{
event: 'log',
timestamp: 1492194569892,
tags: ['connection', 'client', 'error'],
data: Error: 140736014037952: error: 1407609 C: SSL routines: SSL23_GET_CLIENT_HELLO: http request: ../deps/openssl/openssl/ssl/s23_srvr.c:394:at Error(native),
pid: 74537
}
04b0d21
to
f9d0f6e
Compare
- httpolyglot is removed, we no longer automatically redirect from http to https - server.ssl.redirectHttpFromPort option added to allow for http -> https redirect from one port to another - We no longer start the dev server with tls by default, it can be turned on with the --ssl flag, npm start -- --ssl, or ./bin/kibana --dev --ssl - There will currently be error log messages if you connect over the wrong protocol, we have #11209 for downgrading these
…s when serving http errors
f9d0f6e
to
3d8b0c3
Compare
Rebased master, works as expected in my testing. Below are examples when debug logging is 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.
LGTM on green
When serving Kibana over http and a request comes in over https, kibana logs a "Parse Error" to the standard application log.
When serving Kibana over https and a request comes in over http, kibana logs a "routines:SSL23_GET_CLIENT_HELLO:http request" to the standard application log. This won't be testable until the http -> https redirect with httpolyglot is removed. See #10930.
This downgrades both log types to debug output.