jersey-netty-connector v2.47 : Connector is returning 200 OK when decoded result in HttpResponse contains TooLongHttpHeaderException

[sxsubram]

jersey-netty-connector v2.47
JDK 21

In jersey-netty-connector client configuration the following properties are set -
defaultConfig.property(NettyClientProperties.MAX_HEADER_SIZE, 8192 * 2);
defaultConfig.property(NettyClientProperties.MAX_INITIAL_LINE_LENGTH, 8192 * 2);

In the test the server is sending a header that exceeds the MAX_HEADER_SIZE.
invocationBuilder.header("X-LARGE-HEADER", largeHeader);
invocationBuilder.header("X-MY-HEADER", "foo");

When JerseyClientHandler reads the response I see the following in the debugger.

DefaultHttpResponse(decodeResult: failure(io.netty.handler.codec.http.TooLongHttpHeaderException: HTTP header is larger than 16384 bytes.), version: HTTP/1.1)
HTTP/1.1 200 OK
Date: Tue, 09 Dec 2025 22:05:37 GMT
Content-Type: application/json
Content-Length: 22

Even though the netty layer creates TooLongHttpHeaderException, this is not captured in the response processing. The future returned the client does not have the required headers causing downstream processing exceptions.

[jbescos]

I am not really getting the issue, this is the test I have:

public class Issue6045Test extends JerseyTest {

    private static final Logger LOGGER = Logger.getLogger(Issue6045Test.class.getName());

    @Path("/test")
    public static class TestResource {

        @POST
        @Consumes(MediaType.TEXT_PLAIN)
        @Produces(MediaType.TEXT_PLAIN)
        public Response post(String input, @Context HttpHeaders headers) {
            return Response.ok("OK")
                    .header("X-LARGE-HEADER", headers.getHeaderString("X-LARGE-HEADER"))
                    .header("X-MY-HEADER", headers.getHeaderString("X-MY-HEADER"))
                    .build();
        }
    }

    @Override
    protected Application configure() {
        return new ResourceConfig(TestResource.class)
                .register(new LoggingFeature(LOGGER, LoggingFeature.Verbosity.PAYLOAD_ANY));
    }

    @Override
    protected Client getClient() {
        ClientConfig defaultConfig = new ClientConfig();
        defaultConfig.property(NettyClientProperties.MAX_HEADER_SIZE, 8192 * 2);
        defaultConfig.property(NettyClientProperties.MAX_CHUNK_SIZE, 8192 * 2);
        defaultConfig.property(ClientProperties.REQUEST_ENTITY_PROCESSING, RequestEntityProcessing.CHUNKED);
        defaultConfig.property(ClientProperties.CONNECT_TIMEOUT, 10000);
        defaultConfig.register(MultiPartFeature.class);
        defaultConfig.property(LoggingFeature.LOGGING_FEATURE_VERBOSITY_CLIENT, LoggingFeature.Verbosity.PAYLOAD_ANY);
        defaultConfig.property(LoggingFeature.LOGGING_FEATURE_MAX_ENTITY_SIZE, LoggingFeature.DEFAULT_MAX_ENTITY_SIZE * 100);
        defaultConfig.connectorProvider(new NettyConnectorProvider());
        defaultConfig.property(NettyClientProperties.MAX_INITIAL_LINE_LENGTH, 8192 * 2);

        return ClientBuilder.newClient(defaultConfig);
    }

    @Override
    protected TestContainerFactory getTestContainerFactory() throws TestContainerException {
        final Map<String, Object> configurationProperties = new HashMap<>();
        configurationProperties.put(JettyTestContainerProperties.HEADER_SIZE, Integer.MAX_VALUE);
        return new JettyTestContainerFactory(configurationProperties);
    }

    @Test
    public void testLargeHeaderFailsOrSucceeds() {
        WebTarget webTarget = target("test");

        Invocation.Builder invocationBuilder = webTarget.request();
        invocationBuilder.header("user-agent", "oracle-cloud-rest/21.2.1");
        invocationBuilder.header("x-span-id", "12df55e348d780a4");
        invocationBuilder.header("X-LARGE-HEADER", "A".repeat(20_000));
        invocationBuilder.header("X-MY-HEADER", "foo");

        String input = "test message";
        Entity<String> entity = Entity.entity(input, MediaType.TEXT_PLAIN);

        CompletionStage<Response> responseStage =
                invocationBuilder.rx().method("POST", entity);

        responseStage.whenComplete((rsp, t) -> {
            System.out.println("complete.");
        }).handle((rsp, t) -> {
            if (t != null) {
                System.out.println("rsp has exception: " + t);
            } else {
                System.out.println("request completed");
                System.out.println("rsp = " + rsp);
                System.out.println("Status = " + rsp.getStatus());
                System.out.println("X-LARGE-HEADER = " + rsp.getHeaderString("X-LARGE-HEADER"));
                System.out.println("X-MY-HEADER = " + rsp.getHeaderString("X-MY-HEADER"));
                System.out.println("Entity = " + rsp.readEntity(String.class));
            }
            return "";
        }).toCompletableFuture().join();
    }
}

Responds with:

complete.
request completed
rsp = InboundJaxrsResponse{context=ClientResponse{method=POST, uri=http://localhost:43381/test, status=200, reason=OK}}
Status = 200
X-LARGE-HEADER = null
X-MY-HEADER = null

Note the response header is empty, but we have another test verifying that is a correct behavior:
https://github.com/eclipse-ee4j/jersey/blob/bb8a2a1b78e39604f4d283d0176705b143355c[…]t/java/org/glassfish/jersey/netty/connector/HugeHeaderTest.java

Are you able to modify this test in order to reproduce it?. You can run the next:

git clone https://github.com/jbescos/jersey.git
cd jersey
git checkout origin/issue6045
mvn clean install -DskipTests
cd connectors/netty-connector
mvn clean install -Dtest=Issue6045Test

[jbescos]

I am getting the stacktrace with the debugger:

Thread [nioEventLoopGroup-2-1] (Suspended (breakpoint at line 45 in io.netty.handler.codec.http.TooLongHttpHeaderException))	
	io.netty.handler.codec.http.TooLongHttpHeaderException.<init>(java.lang.String) line: 45	
	io.netty.handler.codec.http.HttpObjectDecoder$HeaderParser.newException(int) line: 1224	
	io.netty.handler.codec.http.HttpObjectDecoder$HeaderParser.parse(io.netty.buffer.ByteBuf, java.lang.Runnable) line: 1188	
	io.netty.handler.codec.http.HttpClientCodec$Decoder(io.netty.handler.codec.http.HttpObjectDecoder).readHeaders(io.netty.buffer.ByteBuf) line: 746	
	io.netty.handler.codec.http.HttpClientCodec$Decoder(io.netty.handler.codec.http.HttpObjectDecoder).decode(io.netty.channel.ChannelHandlerContext, io.netty.buffer.ByteBuf, java.util.List<java.lang.Object>) line: 382	
	io.netty.handler.codec.http.HttpClientCodec$Decoder.decode(io.netty.channel.ChannelHandlerContext, io.netty.buffer.ByteBuf, java.util.List<java.lang.Object>) line: 320	
	io.netty.handler.codec.http.HttpClientCodec$Decoder(io.netty.handler.codec.ByteToMessageDecoder).decodeRemovalReentryProtection(io.netty.channel.ChannelHandlerContext, io.netty.buffer.ByteBuf, java.util.List<java.lang.Object>) line: 530	
	io.netty.handler.codec.http.HttpClientCodec$Decoder(io.netty.handler.codec.ByteToMessageDecoder).callDecode(io.netty.channel.ChannelHandlerContext, io.netty.buffer.ByteBuf, java.util.List<java.lang.Object>) line: 469	
	io.netty.handler.codec.http.HttpClientCodec$Decoder(io.netty.handler.codec.ByteToMessageDecoder).channelRead(io.netty.channel.ChannelHandlerContext, java.lang.Object) line: 290	
	io.netty.handler.codec.http.HttpClientCodec(io.netty.channel.CombinedChannelDuplexHandler<I,O>).channelRead(io.netty.channel.ChannelHandlerContext, java.lang.Object) line: 251	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelRead(java.lang.Object) line: 442	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(io.netty.channel.AbstractChannelHandlerContext, java.lang.Object) line: 420	
	io.netty.channel.DefaultChannelPipeline$HeadContext(io.netty.channel.AbstractChannelHandlerContext).fireChannelRead(java.lang.Object) line: 412	
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(io.netty.channel.ChannelHandlerContext, java.lang.Object) line: 1357	
	io.netty.channel.DefaultChannelPipeline$HeadContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelRead(java.lang.Object) line: 440	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(io.netty.channel.AbstractChannelHandlerContext, java.lang.Object) line: 420	
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(java.lang.Object) line: 868	
	io.netty.channel.socket.nio.NioSocketChannel$NioSocketChannelUnsafe(io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe).read() line: 166	
	io.netty.channel.nio.NioEventLoop.processSelectedKey(java.nio.channels.SelectionKey, io.netty.channel.nio.AbstractNioChannel) line: 796	
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized() line: 732	
	io.netty.channel.nio.NioEventLoop.processSelectedKeys() line: 658	
	io.netty.channel.nio.NioEventLoop.run() line: 562	
	io.netty.util.concurrent.SingleThreadEventExecutor$4.run() line: 998	
	io.netty.util.internal.ThreadExecutorMap$2.run() line: 74	
	io.netty.util.concurrent.FastThreadLocalRunnable.run() line: 30	
	io.netty.util.concurrent.FastThreadLocalThread(java.lang.Thread).runWith(java.lang.Object, java.lang.Runnable) line: 1596	
	io.netty.util.concurrent.FastThreadLocalThread(java.lang.Thread).run() line: 1583	

[jbescos]

For reference: #5649

It seems the correct behavior is to return 431 Request Header Fields Too Large. If we return 2XX error, the client does not know that the request was not processed. Do you agree @senivam ?. EDIT: Ignore the question

[jbescos]

With the debugger, Netty is just forwarding the HTTP response code sent from the server. The error 431 should be returned from the server:

I think the client should pass what it receives (we cannot modify status code in the client), but I agree that the HTTP client is not notified about this issue. It looks that header size property is just to avoid memory issues.

[senivam]

I would check if the initial parameters from the configuration

defaultConfig.property(NettyClientProperties.MAX_HEADER_SIZE, 8192 * 2);
defaultConfig.property(NettyClientProperties.MAX_INITIAL_LINE_LENGTH, 8192 * 2);

are really passed to the Netty client. Because if this works properly, then probably the header did not exceed the limit, and that is why the response is transformed from the 431 to the 200 (DefaultHttpResponse is still Netty object, and this is captured there). If you try to send the same header but with a smaller NettyClientProperties.MAX_HEADER_SIZE, does it happen or the 431 code is being returned?

[jbescos]

I would check if the initial parameters from the configuration

defaultConfig.property(NettyClientProperties.MAX_HEADER_SIZE, 8192 * 2);
defaultConfig.property(NettyClientProperties.MAX_INITIAL_LINE_LENGTH, 8192 * 2);

are really passed to the Netty client. Because if this works properly, then probably the header did not exceed the limit, and that is why the response is transformed from the 431 to the 200 (DefaultHttpResponse is still Netty object, and this is captured there). If you try to send the same header but with a smaller NettyClientProperties.MAX_HEADER_SIZE, does it happen or the 431 code is being returned?

I was debugging this and I don't think this is an issue in Netty. If the server responds with 2XX, Netty cannot modify the status code. What Netty does is to set the header to null, to avoid memory issues.

[sxsubram]

The client needs to know about this exception. If you cannot change the http code, can you propagate the exception to the client? Currently we have no visibility into what is causing the downstream errors.

[sxsubram]

@senivam I did check the config values in the debugger.
p.addLast(new HttpClientCodec(maxInitialLineLength, maxHeaderSize, maxChunkSize)); is passing the values to the Netty layer

[jbescos]

I guess that we should rethrow a ResponseProcessingException in the client, as it is said here:
https://download.oracle.com/javaee-archive/jax-rs-spec.java.net/users/att-2621/spec.pdf

4.5.2 Client Runtime
When a provider method throws an exception, the JAX-RS client runtime will map it to an instance of
ProcessingException if thrown while processing a request, and to a ResponseProcessingException
if thrown while processing a response. 

I have to check whether Netty is eating the exception silently, or is Jersey who is doing that.

[jbescos]

The nature of Netty is asynchornous, so Jersey does not catch exceptions. It is Netty who will notify the exceptions in this method:

jersey/connectors/netty-connector/src/main/java/org/glassfish/jersey/netty/connector/JerseyClientHandler.java

Line 232 in bb8a2a1

public void exceptionCaught(ChannelHandlerContext ctx, final Throwable cause) {

However, Netty is no notifying this as an error, as we can see in the next stack:

Thread [nioEventLoopGroup-2-1] (Suspended (breakpoint at line 105 in org.glassfish.jersey.netty.connector.JerseyClientHandler))	
	org.glassfish.jersey.netty.connector.JerseyClientHandler.notifyResponse(io.netty.channel.ChannelHandlerContext) line: 105	
	org.glassfish.jersey.netty.connector.JerseyClientHandler.channelReadComplete(io.netty.channel.ChannelHandlerContext) line: 88	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelReadComplete() line: 486	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(io.netty.channel.AbstractChannelHandlerContext) line: 463	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).fireChannelReadComplete() line: 456	
	io.netty.handler.timeout.IdleStateHandler.channelReadComplete(io.netty.channel.ChannelHandlerContext) line: 298	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelReadComplete() line: 484	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(io.netty.channel.AbstractChannelHandlerContext) line: 463	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).fireChannelReadComplete() line: 456	
	io.netty.handler.codec.http.HttpContentDecompressor(io.netty.handler.codec.http.HttpContentDecoder).channelReadComplete(io.netty.channel.ChannelHandlerContext) line: 196	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelReadComplete() line: 486	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(io.netty.channel.AbstractChannelHandlerContext) line: 463	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).fireChannelReadComplete() line: 456	
	io.netty.channel.CombinedChannelDuplexHandler$1(io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext).fireChannelReadComplete() line: 442	
	io.netty.handler.codec.http.HttpClientCodec$Decoder(io.netty.handler.codec.ByteToMessageDecoder).channelReadComplete(io.netty.channel.ChannelHandlerContext) line: 359	
	io.netty.handler.codec.http.HttpClientCodec(io.netty.channel.CombinedChannelDuplexHandler<I,O>).channelReadComplete(io.netty.channel.ChannelHandlerContext) line: 261	
	io.netty.channel.DefaultChannelHandlerContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelReadComplete() line: 484	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(io.netty.channel.AbstractChannelHandlerContext) line: 463	
	io.netty.channel.DefaultChannelPipeline$HeadContext(io.netty.channel.AbstractChannelHandlerContext).fireChannelReadComplete() line: 456	
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelReadComplete(io.netty.channel.ChannelHandlerContext) line: 1362	
	io.netty.channel.DefaultChannelPipeline$HeadContext(io.netty.channel.AbstractChannelHandlerContext).invokeChannelReadComplete() line: 482	
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(io.netty.channel.AbstractChannelHandlerContext) line: 463	
	io.netty.channel.DefaultChannelPipeline.fireChannelReadComplete() line: 874	
	io.netty.channel.socket.nio.NioSocketChannel$NioSocketChannelUnsafe(io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe).read() line: 171	
	io.netty.channel.nio.NioEventLoop.processSelectedKey(java.nio.channels.SelectionKey, io.netty.channel.nio.AbstractNioChannel) line: 796	
	io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized() line: 732	
	io.netty.channel.nio.NioEventLoop.processSelectedKeys() line: 658	
	io.netty.channel.nio.NioEventLoop.run() line: 562	
	io.netty.util.concurrent.SingleThreadEventExecutor$4.run() line: 998	
	io.netty.util.internal.ThreadExecutorMap$2.run() line: 74	
	io.netty.util.concurrent.FastThreadLocalRunnable.run() line: 30	
	io.netty.util.concurrent.FastThreadLocalThread(java.lang.Thread).runWith(java.lang.Object, java.lang.Runnable) line: 1596	
	io.netty.util.concurrent.FastThreadLocalThread(java.lang.Thread).run() line: 1583	

I suggest that you open an issue in Netty to know why this is not notified as an error. I don't see whether there is a Netty configuration to allow this to happen.

[senivam]

As per my investigation, Netty does not mark this as an error response:

The maximum size in bytes of an http request header. Exceeding the size generates a different response across server implementations.
Jetty: generates a 431 error message
Netty: the header is dropped/ignored, but don't fail
Undertow: generates an empty 400 response, and the connection is closed.

The reference is taken from https://www.javadoc.io/doc/io.jooby/jooby/latest/io.jooby/io/jooby/ServerOptions.html

[sxsubram]

we need a solution similar to this - (https://github.com/netty/netty/issues/12769) in the jersey code.