| Name | Meaning |
|---|---|
| {@code maxInitialLineLength} | The maximum length of the initial line (e.g. {@code "HTTP/1.0 200 OK"}) If the length of the initial line exceeds this value, a {@link TooLongFrameException} will be raised. |
| {@code maxHeaderSize} | The maximum length of all headers. If the sum of the length of each header exceeds this value, a {@link TooLongFrameException} will be raised. |
| {@code 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 {@link HttpChunk}s. 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 {@link HttpChunk}s in your handler, insert {@link HttpChunkAggregator}after this decoder in the {@link ChannelPipeline}. |
Unlike other HTTP requests, the successful response of a HEAD request does not have any content even if there is Content-Length header. Because {@link HttpResponseDecoder} is not able to determine if theresponse currently being decoded is associated with a HEAD request, you must override {@link #isContentAlwaysEmpty(HttpMessage)} to returntrue for the response of the HEAD request.
If you are writing an HTTP client that issues a HEAD request, please use {@link HttpClientCodec} instead of this decoder. It will performadditional state management to handle the responses for HEAD requests correctly.
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.
{@link HttpClientCodec} also handles this edge case correctly, so you have touse {@link HttpClientCodec} if you are writing an HTTP client that issues aCONNECT request.
| Name | Meaning |
|---|---|
| {@code maxInitialLineLength} | The maximum length of the initial line (e.g. {@code "HTTP/1.0 200 OK"}) If the length of the initial line exceeds this value, a {@link TooLongFrameException} will be raised. |
| {@code maxHeaderSize} | The maximum length of all headers. If the sum of the length of each header exceeds this value, a {@link TooLongFrameException} will be raised. |
| {@code 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 {@link HttpContent}s. 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 {@link HttpContent}s in your handler, insert {@link HttpObjectAggregator}after this decoder in the {@link ChannelPipeline}. |
Unlike other HTTP requests, the successful response of a HEAD request does not have any content even if there is Content-Length header. Because {@link HttpResponseDecoder} is not able to determine if theresponse currently being decoded is associated with a HEAD request, you must override {@link #isContentAlwaysEmpty(HttpMessage)} to returntrue for the response of the HEAD request.
If you are writing an HTTP client that issues a HEAD request, please use {@link HttpClientCodec} instead of this decoder. It will performadditional state management to handle the responses for HEAD requests correctly.
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.
{@link HttpClientCodec} also handles this edge case correctly, so you have touse {@link HttpClientCodec} if you are writing an HTTP client that issues aCONNECT request.
| |