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
Correctly handle non handshake commands when using SniHandler #4703
Conversation
@trustin @nmittler @Scottmitch PTAL |
@ejona86 might be interested as well |
offset += extensionLength; | ||
} | ||
break loop; | ||
} else { |
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 think if you structure this the opposite way, you can get rid of the break loop
above:
if (in.readableBytes() < packetLength) {
// client hello incomplete try again to decode once more data is ready.
return;
}
...
// Fall-through
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.
you are right... let me fix this
Motivation: As we can only handle handshake commands to parse SNI we should try to skip alert and change cipher spec commands a few times before we fallback to use a default SslContext. Modifications: - Use default SslContext if no application data command was received - Use default SslContext if after 4 commands we not received a handshake command - Simplify code - Eliminate multiple volatile fields - Rename SslConstants to SslUtils - Share code between SslHandler and SniHandler by moving stuff to SslUtils Result: Correct handling of non handshake commands and cleaner code.
76d6187
to
36e1924
Compare
I wonder creating an extra object to reduce the number of volatile writes seems like an overkill to me. Besides that, looks good to me. :-) |
@trustin honestly the object is only created once and it seems more clean (as both fields just be updated together) so I would like to keep it like it is :) |
lgtm! |
Motivation:
As we can only handle handshake commands to parse SNI we should try to skip alert and change cipher spec commands a few times before we fallback to use a default SslContext.
Modifications:
Result:
Correct handling of non handshake commands and cleaner code.