Class Http2MultiplexHandler

  • All Implemented Interfaces:
    ChannelHandler, ChannelInboundHandler, ChannelOutboundHandler

    public final class Http2MultiplexHandler
    extends Http2ChannelDuplexHandler
    An HTTP/2 handler that creates child channels for each stream. This handler must be used in combination with Http2FrameCodec.

    When a new stream is created, a new Http2StreamChannel is created for it. Applications send and receive Http2StreamFrames on the created channel. ByteBufs cannot be processed by the channel; all writes that reach the head of the pipeline must be an instance of Http2StreamFrame. Writes that reach the head of the pipeline are processed directly by this handler and cannot be intercepted.

    The child channel will be notified of user events that impact the stream, such as Http2GoAwayFrame and Http2ResetFrame, as soon as they occur. Although Http2GoAwayFrame and Http2ResetFrame signify that the remote is ignoring further communication, closing of the channel is delayed until any inbound queue is drained with Channel.read(), which follows the default behavior of channels in Netty. Applications are free to close the channel in response to such events if they don't have use for any queued messages. Any connection level events like Http2SettingsFrame and Http2GoAwayFrame will be processed internally and also propagated down the pipeline for other handlers to act on.

    Outbound streams are supported via the Http2StreamChannelBootstrap.

    ChannelConfig.setMaxMessagesPerRead(int) and ChannelConfig.setAutoRead(boolean) are supported.

    Reference Counting

    Some Http2StreamFrames implement the ReferenceCounted interface, as they carry reference counted objects (e.g. ByteBufs). The multiplex codec will call ReferenceCounted.retain() before propagating a reference counted object through the pipeline, and thus an application handler needs to release such an object after having consumed it. For more information on reference counting take a look at the reference counted docs.

    Channel Events

    A child channel becomes active as soon as it is registered to an EventLoop. Therefore, an active channel does not map to an active HTTP/2 stream immediately. Only once a Http2HeadersFrame has been successfully sent or received, does the channel map to an active HTTP/2 stream. In case it is not possible to open a new HTTP/2 stream (i.e. due to the maximum number of active streams being exceeded), the child channel receives an exception indicating the cause and is closed immediately thereafter.

    Writability and Flow Control

    A child channel observes outbound/remote flow control via the channel's writability. A channel only becomes writable when it maps to an active HTTP/2 stream . A child channel does not know about the connection-level flow control window. ChannelHandlers are free to ignore the channel's writability, in which case the excessive writes will be buffered by the parent channel. It's important to note that only Http2DataFrames are subject to HTTP/2 flow control.

    Closing a Http2StreamChannel

    Once you close a Http2StreamChannel a Http2ResetFrame will be sent to the remote peer with Http2Error.CANCEL if needed. If you want to close the stream with another Http2Error (due errors / limits) you should propagate a Http2FrameStreamException through the ChannelPipeline. Once it reaches the end of the ChannelPipeline it will automatically close the Http2StreamChannel and send a Http2ResetFrame with the unwrapped Http2Error set. Another possibility is to just directly write a Http2ResetFrame to the Http2StreamChannell.