Class HttpServerCodec.HttpServerRequestDecoder

All Implemented Interfaces:
ChannelHandler, ChannelInboundHandler
Enclosing class:
HttpServerCodec

private final class HttpServerCodec.HttpServerRequestDecoder extends HttpRequestDecoder
  • Field Details

    • discard

      private boolean discard
  • Constructor Details

  • Method Details

    • decode

      protected void decode(ChannelHandlerContext ctx, ByteBuf buffer, List<Object> out) throws Exception
      Description copied from class: ByteToMessageDecoder
      Decode the from one ByteBuf to an other. This method will be called till either the input ByteBuf has nothing to read when return from this method or till nothing was read from the input ByteBuf.
      Overrides:
      decode in class HttpObjectDecoder
      Parameters:
      ctx - the ChannelHandlerContext which this ByteToMessageDecoder belongs to
      buffer - the ByteBuf from which to read data
      out - the List to which decoded messages should be added
      Throws:
      Exception - is thrown if an error occurs
    • handleTransferEncodingChunkedWithContentLength

      protected void handleTransferEncodingChunkedWithContentLength(HttpMessage message)
      Description copied from class: HttpObjectDecoder
      Invoked when a message with both a "Transfer-Encoding: chunked" and a "Content-Length" header field is detected. The default behavior is to throw a ContentLengthNotAllowedException exception, but this method could be overridden to change the behavior (to, e.g., remove the Content-Length header value.

      See: RFC 9112, Section 6.1-15.

          A server MAY reject a request that contains both Content-Length and Transfer-Encoding
          or process such a request in accordance with the Transfer-Encoding alone.
          Regardless, the server MUST close the connection after responding to such a request
          to avoid the potential attacks.
      
      Since Netty itself cannot track the request/response pairing, it cannot guarantee that the connection is closed immediately after the response is sent. As such, it is safer to immediately reject the request.

      Note: RFC 7230 (the previous HTTP/1.1 RFC) allowed the Content-Length header to simply be ignored, in the presence of a Transfer-Encoding header, but this practice is now obsolete and considered unsafe. The RFC 7230 behavior can be restored in the following ways:

      Note: This method is only called for HTTP/1.1 requests. Under the default configuration, earlier HTTP protocol versions carrying a Transfer-Encoding header are rejected before reaching this point. However, if HttpDecoderConfig.setUseRfc9112TransferEncoding(boolean) is set to false (see above), that rejection does not happen — a non-HTTP/1.1 message can then legitimately carry Transfer-Encoding without being rejected for it, though this method specifically remains HTTP/1.1-only and is not invoked for such messages.

      Overrides:
      handleTransferEncodingChunkedWithContentLength in class HttpObjectDecoder