Class HttpResponseDecoder

java.lang.Object
io.netty.channel.ChannelHandlerAdapter
io.netty.channel.ChannelInboundHandlerAdapter
io.netty.handler.codec.ByteToMessageDecoder
io.netty.handler.codec.http.HttpObjectDecoder
io.netty.handler.codec.http.HttpResponseDecoder
All Implemented Interfaces:
ChannelHandler, ChannelInboundHandler
public class HttpResponseDecoder extends HttpObjectDecoder
Decodes ByteBufs into HttpResponses and HttpContents.

Parameters that prevents excessive memory consumption

NameMeaning
maxInitialLineLength The maximum length of the initial line (e.g. "HTTP/1.0 200 OK") If the length of the initial line exceeds this value, a TooLongHttpLineException will be raised.
maxHeaderSize The maximum length of all headers. If the sum of the length of each header exceeds this value, a TooLongHttpHeaderException will be raised.
maxChunkSize The maximum length of the content or each chunk. If the content length exceeds this value, the transfer encoding of the decoded response will be converted to 'chunked' and the content will be split into multiple HttpContents. If the transfer encoding of the HTTP response is 'chunked' already, each chunk will be split into smaller chunks if the length of the chunk exceeds this value. If you prefer not to handle HttpContents in your handler, insert HttpObjectAggregator after this decoder in the ChannelPipeline.

Parameters that control parsing behavior

NameDefault valueMeaning
allowDuplicateContentLengths false When set to false, will reject any messages that contain multiple Content-Length header fields. When set to true, will allow multiple Content-Length headers only if they are all the same decimal value. The duplicated field-values will be replaced with a single valid Content-Length field. See RFC 7230, Section 3.3.2.
allowPartialChunks true If the length of a chunk exceeds the ByteBufs readable bytes and allowPartialChunks is set to true, the chunk will be split into multiple HttpContents. Otherwise, if the chunk size does not exceed maxChunkSize and allowPartialChunks is set to false, the ByteBuf is not decoded into an HttpContent until the readable bytes are greater or equal to the chunk size.

Decoding a response for a HEAD request

Unlike other HTTP requests, the successful response of a HEAD request does not have any content even if there is Content-Length header. Because HttpResponseDecoder is not able to determine if the response currently being decoded is associated with a HEAD request, you must override HttpObjectDecoder.isContentAlwaysEmpty(HttpMessage) to return true for the response of the HEAD request.

If you are writing an HTTP client that issues a HEAD request, please use HttpClientCodec instead of this decoder. It will perform additional state management to handle the responses for HEAD requests correctly.

Decoding a response for a CONNECT request

You also need to do additional state management to handle the response of a CONNECT request properly, like you did for HEAD. One difference is that the decoder should stop decoding completely after decoding the successful 200 response since the connection is not an HTTP connection anymore.

HttpClientCodec also handles this edge case correctly, so you have to use HttpClientCodec if you are writing an HTTP client that issues a CONNECT request.

Header Validation

It is recommended to always enable header validation.

Without header validation, your system can become vulnerable to CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') .

This recommendation stands even when both peers in the HTTP exchange are trusted, as it helps with defence-in-depth.