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.

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

Ensure IdleTimeoutHandler receives always channelRead events #2660

Merged
merged 2 commits into from
Jan 20, 2023

Conversation

violetagg
Copy link
Member

  • When the server is configured with HTTP/1.1 and H2C ensure Http2MultiplexHandler is at the end of the pipeline because this handler doesn't forward all channelRead events.
  • When the server is configured with HTTP/1.1 and H2 and the client sends HTTP/1.1, when channelActive event happens, HttpTrafficHandler is still not in the pipeline. In this use case add IdleTimeoutHandler when HttpTrafficHandler is added to the pipeline.

Fixes #2649

- When the server is configured with HTTP/1.1 and H2C ensure Http2MultiplexHandler
is at the end of the pipeline because this handler doesn't forward all channelRead events.
- When the server is configured with HTTP/1.1 and H2 and the client sends HTTP/1.1,
when channelActive event happens, HttpTrafficHandler is still not in the pipeline.
In this use case add IdleTimeoutHandler when HttpTrafficHandler is added to the pipeline.

Fixes #2649
@violetagg violetagg added the type/bug A general bug label Jan 19, 2023
@violetagg violetagg added this to the 1.0.28 milestone Jan 19, 2023
@violetagg violetagg requested a review from a team January 19, 2023 09:42
Copy link
Member

@pderop pderop left a comment

Choose a reason for hiding this comment

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

Looks good to me.

One minor thing: it seems that in HttpTrafficHandler.channelActive method line 138, the IdleTimeoutHandler.addIdleTimeoutHandler(ctx.pipeline(), idleTimeout); call can be removed

…r is added at the point when HTTP/1.1 is negotiated

Previously it was added with HttpTrafficHandler#handlerAdded, for this use case this is correct,
but for the other use cases we don't want to add IdleTimeoutHandler at this point because
we don't want this handler to participate in the TLS handshake.
@violetagg
Copy link
Member Author

violetagg commented Jan 20, 2023

Looks good to me.

One minor thing: it seems that in HttpTrafficHandler.channelActive method line 138, the IdleTimeoutHandler.addIdleTimeoutHandler(ctx.pipeline(), idleTimeout); call can be removed

On a second thought, although that HttpTrafficHandler#handlerAdded is ok for the use case server HTTP/1.1 and HTTP/2 where the negotiated protocol is HTTP/1.1, it is not ok for the rest of the use cases because we don't want IdleTimeoutHandler to participate in the TLS handshake.
Please check the new change.

Copy link
Member

@pderop pderop left a comment

Choose a reason for hiding this comment

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

+1

@violetagg
Copy link
Member Author

@pderop Thanks for the review!

@violetagg violetagg merged commit 21bd6ef into 1.0.x Jan 20, 2023
@violetagg violetagg deleted the issue-2649 branch January 20, 2023 10:12
violetagg added a commit that referenced this pull request Jan 20, 2023
violetagg added a commit that referenced this pull request Jan 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug A general bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GOAWAY http/2 frame intermittently observed on high traffic on adding idleTimeout
2 participants