Jetty HttpClient in HTTP/1.1 mode, using Blocking APIs, will not idle timeout when encountering unexpected 1xx (Informational) status codes.

[reschke]

[HTTP/1.1 104 Upload Resumption Supported
Upload-Offset: 50

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 13

Hello, world.

Test cases in https://github.com/greenbytes/java-http-1xx-tests; run

mvn clean install -Dtest=JettyHttpClientTests#testJettyHttpClient104_1

Note that the problem is the same for any informational status code >= 103.

[joakime]

Jetty HttpClient implements 1xx support via it's org.eclipse.jetty.client.ProtocolHandler facilities.

• 100 : ContinueProtocolHandler
• 101 : UpgradeProtocolHandler
• 102 : ProcessingProtocolHandler
• 103 : EarlyHintsProtocolHandler

Your test cases for Jetty HttpClient
https://github.com/greenbytes/java-http-1xx-tests/blob/main/src/test/java/org/greenbytes/http/test1xx/JettyHttpClientTests.java

Uses the following code snippet for Jetty HttpClient ...

        ContentResponse response = client.newRequest(TESTURI)
                    .version(HttpVersion.HTTP_1_1)
                    .send();

That format uses GET only, and assumes a complete response (the use of the ContentResponse API).
Your test server replies with a response line with the status code (no reason), and then a 200 response with some optional headers, and occasionally some body content (depends on status code of the test case).

We have unit tests for all of the above status codes on HTTP/1.1, HTTP/2, and HTTP/3.

We pass your tests for 100, 101, 102, 103, and 200, yet your README.md says otherwise.
There's no handling for 104 or 199, so they fail appropriately, as there's no shipped client side ProtocolHandler for them to support the use of the ContentResponse API.

If a user of Jetty HttpClient wants to use any arbitrary 1xx protocol (eg: HTTP/1.1 179 foo), then they have two options.

1. Use the listener APIs to participate in the exchange doing whatever they want to do to handle the exchange to reach a complete state (this means you don't use the ContentResponse API).
2. Implement their own ProtocolHandler to handle the exchange and provide the "content" that the ContentResponse object will make available (you'll implement a Jetty Client org.eclipse.jetty.client.Response.Listener to do this btw).

Note about status code 104 Upload Resumption Supported

The HTTP Status code 104 Upload Resumption Supported is listed as a TEMPORARY assignment.
There's no point in implementing support for it until it's actually a real spec.

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

104 Upload Resumption Supported (TEMPORARY - registered 2024-11-13, extension registered 2025-09-15, expires 2026-11-13) [draft-ietf-httpbis-resumable-upload-05]

The various conversations (in the ietf-http-wg mailing list) around this proposed status code are not promising at the moment.

Things not yet addressed in the draft-ietf-httpbis-resumable-upload-12 draft.

• Server side resource exhaustion/expiration (the allowed actions on the server side, and how to report it to the client). This is a giant red flag of a DOS attack.
• Client side resumption of uploads of mime/multipart and its random boundary requirements.
• How compression fits into things? (esp with dictionaries in play)

I personally don't see this becoming an actual supported spec as it stands right now, and judging from the conversations in the ietf-http-wg on people attempting to implement it (server and client side) this will probably either evolve greatly into something unrecognizable from what we see today, or just be dropped.

[reschke]

Thank you for the detailed response. Unfortunately, however, it largely misses the central point I was trying to make.

• First, you are correct that the summary incorrectly states that a response with status code 200 failed. That is obviously incorrect; apologies for the mistake. I will fix the summary shortly.

• The purpose of the test suite is to verify that clients correctly handle informational responses (1xx), which is a requirement of HTTP, rather than an optional feature. See RFC 9110, Section 15.2. A client that does not correctly handle informational responses breaks as soon as a server begins sending a previously unknown 1xx status code.

• Exposing the contents of an informational response - i.e., its status code and header fields - is not itself a requirement. However, doing so is useful because it allows clients to inspect and make use of the information provided by the server. Unfortunately, at present, Apache HttpClient 5 appears to be the only client that exposes this information (I did not check yet with Jetty because of the other issues).

Whether or not the Resumable Upload Internet-Draft is ultimately approved is therefore completely irrelevant to the issue being tested here. The test suite is not intended to establish whether a particular draft has been standardized. It simply observes whether a client correctly implements the HTTP requirement to handle 1xx responses generically, or whether it special-cases newly introduced 1xx status codes.

That distinction is the central point of the test, and it is independent of the status of any particular Internet-Draft.

[reschke]

And...:

... and occasionally some body content (depends on status code of the test case).

Sending a response body in an informational response by definition is impossible (the body would be interpreted as the next message).

[reschke]

fix1xx.patch

As suspected, adding a generic handler for 1xx makes the client compliant wrt 1xx. The change is lame; it would be sufficient to rename EarlyHintsProtocolHandler and widen the range of supported status codes to 103...199 (or do the equivalent with ProcessingProtocolHandler).

[joakime]

• The purpose of the test suite is to verify that clients correctly handle informational responses (1xx), which is a requirement of HTTP, rather than an optional feature. See RFC 9110, Section 15.2. A client that does not correctly handle informational responses breaks as soon as a server begins sending a previously unknown 1xx status code.

The section you are likely referring to is ...

A client MUST be able to parse one or more 1xx responses received prior to a final
response, even if the client does not expect one. A user agent MAY ignore
unexpected 1xx responses.

The Jetty HttpClient does parse one or more 1xx responses received.
The chosen Jetty HttpClient API in your test cases is the ContentResponse API (this is not the only API choice).
This is a blocking API call that expects a valid/sane/complete response with response status, response header fields, and optional response body content (body content determined by HTTP protocol).

Jetty HttpClient, when encountering an unexpected 1xx response is now unable to produce a ContentResponse object.

Here's an example of using the existing Jetty HttpClient (without your patch) and choosing to ignore unexpected 1xx responses.

ContentResponse response = client.newRequest(TESTURI)
    .version(HttpVersion.HTTP_1_1)
    .onResponseSuccess((resp) ->
    {
        // If we got an onResponseSuccess status as Informational, then this is an unexpected 1xx.
        if (HttpStatus.isInformational(resp.getStatus()))
        {
            // Ignore it.
            // Note: Ignoring unexpected 1xx responses is unsafe to do.
            HttpConversation conversation = ((HttpRequest)resp.getRequest()).getConversation();
            conversation.updateResponseListeners(null);
            HttpExchange exchange = conversation.getExchanges().peekLast();
            exchange.resetResponse();
        }
    })
    .send();

While the spec says 1xx is informational and can be safely ignored, in reality this isn't true.
Take for example, 101 Switching Protocols, a 1xx status that cannot be safely ignored. (This breaks the HTTP/1.1 connection state, and will also never see a "final response")
If we start ignoring unexpected 1xx, and suddenly an new 1xx gets introduced that has unexpected impacts to the conversation like 101 then we have a potential CVE on our hands.

Example, we have methods for testing status codes to see if they are informational and something we call interim simply because of this reality.

jetty.project/jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpStatus.java

Lines 317 to 329 in 31716eb

	/**
	* Tests whether the status code is of the
	* {@code Informational} message category as defined in
	* <a href="https://www.rfc-editor.org/rfc/rfc9110.html">RFC 9110</a>.
	*
	* @param code the code to test.
	* @return true if within range of codes that belongs to
	* {@code Informational} codes.
	*/
	public static boolean isInformational(int code)
	{
	return ((100 <= code) && (code <= 199));
	}

jetty.project/jetty-core/jetty-http/src/main/java/org/eclipse/jetty/http/HttpStatus.java

Lines 331 to 340 in 31716eb

	/**
	* Tests whether the status code is informational but not {@code 101 Switching Protocols}.
	*
	* @param code the code to test
	* @return whether the status code is informational but not {@code 101 Switching Protocols}
	*/
	public static boolean isInterim(int code)
	{
	return isInformational(code) && code != HttpStatus.SWITCHING_PROTOCOLS_101;
	}

BTW, There's nothing in RFC9110 that says a HTTP/1.1 user-agent must implement 1xx handling (even 100-Continue). According to the spec it's safe to parse all 1xx responses, and treat them all as unexpected, waiting for the final response. A scenario which will result in a broken HTTP/1.1 user-agent.

[joakime]

I'd be more in favor of having this exist as an easier to enable, but optional, behavior for ignoring unexpected 1xx.

Having a built-in / always on / defaulted / configuration is unsafe IMO.

It could exist as:

1. A high level Jetty HttpClient API to apply to all HTTP versions.
   eg:

   HttpClient.newRequest()
       .ignoreUnexpected1xx()...

2. A HTTP Version specific API.
   eg:

   HttpClientTransportOverHTTP transport = new HttpClientTransportOverHTTP();
   transport.setIgnoreUnexpected1xxStatusCodes(true);
   
   HttpClient client = new HttpClient(transport);
   client.start();

3. A pre-built, but not default included ProtocolHandler
   eg:

   HttpClient client = new HttpClient();
   client.getProtocolHandlers().put(new IgnoreUnexpected1xxHandler());
   client.start();

4. A pre-build onResponseSuccess listener
   eg:

   ContentResponse response = client.newRequest(TESTURI)
       .version(HttpVersion.HTTP_1_1)
       .onResponseSuccess(new IgnoreUnexpected1xxHandler())
       .send();            

And documenting whatever choice we land on.

[reschke]

https://greenbytes.de/tech/specs/rfc9110.html#rfc.section.15.2.p.3

A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.

There is no wiggle room here. This is a MUST-level requirement. If the client, by default, trips over an expected 1xx, it's simply non-compliant. It's really as simple as that. (and yes, 100 and 101 are special, but no new special ones can be introduced).

(FWIW: "even" browsers get this right, and so do all other Java clients that I have tested)

If it's important for you to make this configurable by all means make it an opt-out, and make the conforming behaviour the default.

On the other points:

This is a blocking API call that expects a valid/sane/complete response with response status, response header fields, and optional response body content (body content determined by HTTP protocol).

Waiting for a complete response is good (and in fact expected by the caller). What's not ok is to either hang or to return invalid content.

For instance, with

$ mvn clean install -Dtest=JettyHttpClientTests#testJettyHttpClient199

the result is:

S: request: GET / HTTP/1.1<CR><LF>Accept-Encoding: gzip<CR><LF>User-Agent: Jetty/12.0.12<CR><LF>Host: localhost:8080<CR><LF><CR><LF>
S: response: HTTP/1.1 199 <CR><LF><CR><LF>HTTP/1.1 200 OK<CR><LF>Content-Type: text/plain<CR><LF>Content-Length: 13<CR><LF><CR><LF>Hello, world.
S: (closed)

So the client hangs on a completely conforming HTTP/1.1 response and never sees the final message. This is a bug.

If we start ignoring unexpected 1xx, and suddenly an new 1xx gets introduced that has unexpected impacts to the conversation like 101 then we have a potential CVE on our hands.

This by definition can not be happen. If that is not clear enough in RFC 9110, reporting an erratum would be the right thing (https://www.rfc-editor.org/series/rfc-errata/#how-to-report-an-erratum).

FWIW: are you saying that all the other user agents are risking a CVE?

[joakime]

A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.

There is no wiggle room here. This is a MUST-level requirement. If the client, by default, trips over an expected 1xx, it's simply non-compliant. It's really as simple as that. (and yes, 100 and 101 are special, but no new special ones can be introduced).

(FWIW: "even" browsers get this right, and so do all other Java clients that I have tested)

Again, We do parse 1xx responses (the MUST requirement).
Using the blocking (high level) ContentResponse API makes the unexpected 1xx stop attempting to process the content (this is the MAY requirement, which has no requirement for a final response).

Looking at how you use the other java clients, I can easily change the Jetty HttpClient to be totally async, just like Apache HttpClient 5, and get the same results as Apache HttpClient 5 (complete with interim notifications, your "1xx receipts reported" column on the README).

Example:

    private void testJettyHttpClient(Thread server) throws Exception
    {
        HttpClient client = new HttpClient();
        client.start();
        // we don't want HttpClient to automatically decode the response
        client.getContentDecoderFactories().clear();
        // We don't want HttpClient to hide the protocol handling
        client.getProtocolHandlers().clear();
        try
        {
            CompletableFuture<Response> response = new CompletableFuture<>();
            AtomicReference<String> responseBody = new AtomicReference<>();

            client.newRequest(TESTURI)
                .version(HttpVersion.HTTP_1_1)
                .send(new BufferingResponseListener()
                {
                    public void onSuccess(Response resp)
                    {
                        if (HttpStatus.isInformational(resp.getStatus()))
                        {
                            System.out.println("JettyClient: onSuccess: [Informational]: " + resp);
                            // Allow the conversation to flow to its eventual end.
                            HttpConversation conversation = ((HttpRequest)resp.getRequest()).getConversation();
                            conversation.updateResponseListeners(null);
                            HttpExchange exchange = conversation.getExchanges().peekLast();
                            exchange.resetResponse();
                        }
                        else
                        {
                            System.out.println("JettyClient: onSuccess: Response: " + resp);
                        }
                    }

                    @Override
                    public void onFailure(Response resp, Throwable failure)
                    {
                        System.out.println("JettyClient: onFailure: Response: " + resp);
                        failure.printStackTrace(System.out);
                        response.completeExceptionally(failure);
                    }

                    @Override
                    public void onComplete(Result result)
                    {
                        if (result.isFailed())
                            response.completeExceptionally(result.getResponseFailure());
                        else
                        {
                            // Assuming UTF-8
                            responseBody.set(getContentAsString(UTF_8));
                            response.complete(result.getResponse());
                        }
                    }
                });

            Response clientResponse = response.get(5, TimeUnit.SECONDS);

            int status = clientResponse.getStatus();
            String content = responseBody.get();

            logStatus(status, clientResponse.getReason());
            logContent(content);

            assertEquals(200, status);
            assertEquals(CONTENT, content);
        }
        finally
        {
            client.stop();
            server.join();
        }
    }

[reschke]

What's really relevant is: will a user of the Jetty client experience breakage when the server sends something "new" - but entirely compliant with RFC 9110 - or not.

The answer is yes, it will break when using the simplest possible way to create a client (right?). So, in that case, the client is broken. No other client library has that problem. Nor browsers.

It's nice that you can make it work (and that you can make it expose the interims); yes. But as long as this is not the default, the client is broken. Really. Seriously.

(And, just in doubt, look at the author list on RFC 9110 if you haven't already done that).

[joakime]

What's really relevant is: will a user of the Jetty client experience breakage when the server sends something "new" - but entirely compliant with RFC 9110 - or not.

This 1xx spec MUST statement was introduced in RFC2616, and unchanged all the way thru RFC9110.
Nobody has filed an errata on it in against any of the RFCs.

The answer is yes, it will break when using the simplest possible way to create a client (right?). So, in that case, the client is broken. No other client library has that problem. Nor browsers.

Simplest is subjective.
Your Apache HttpClient 5 test case is actually more complicated than the async example I provided above.

It's nice that you can make it work (and that you can make it expose the interims); yes. But as long as this is not the default, the client is broken. Really. Seriously.

This implies that it is expected that all user-agents should be able to communicate with all servers, in all possible server configurations, without ever modifying the user-agent to fit the resource requirements imposed by the server endpoint.

Back when HTTP/1.0 was first a spec (RFC2068) (heck, even back in HTTP/0.9), the above statement is easily true.
But when HTTP/1.1 (RFC2616) and the new 101 Switching Protocols was introduced, the above statement is no longer true.
Since RFC7230, there's been other pressures in various HTTP adjacent specs making that statement no longer true.

(And, just in doubt, look at the author list on RFC 9110 if you haven't already done that).

I know who you were before my first reply. Yes you are well known. Been reading your messages in ietf-http (and ietf-hybi) for the past 20-ish years. Noticed you in various discussions here and there in mailing lists, then really get involved during the updates to RFC2616 (leading to RFC7230) and even in hybi / RFC6455.

Note: the "unexpected 1xx" safety issue is only present in HTTP/1.1 due to its connection handling. HTTP/2 and HTTP/3 have no such safety issues.

We are leaving this open and discussing internally, but any changes for this wont happen in the Jetty 12.x codebase.
It's been put in the Jetty 13.x backlog.

[joakime]

For Jetty Devs:

The most important part of these test cases is that the no timeouts trigger when using the Blocking APIs.
The client idle timeout, the request idle timeout, and the destination idle timeout all fail to trigger in these "unexpected 1xx" scenarios (eg: 140, 199).

[reschke]

Thanks so far; a few minor points:

Simplest is subjective.

Ok, maybe in lines of code?

Your Apache HttpClient 5 test case is actually more complicated than the async example I provided above.

Yes, that is unbelievable complex and falls into the category : "you can do this, but it won't be nice".

This implies that it is expected that all user-agents should be able to communicate with all servers, in all possible server configurations, without ever modifying the user-agent to fit the resource requirements imposed by the server endpoint.

"with all compliant servers" - yes. This is essential for evolvability. A client should never break if one of the known extension points are used (such as new status codes (informational or not), field names, method names, etc).

But when HTTP/1.1 (RFC2616) and the new 101 Switching Protocols was introduced, the above statement is no longer true.

Getting a 101 without having asked for it seems to be a server error, no?

Since RFC7230, there's been other pressures in various HTTP adjacent specs making that statement no longer true.

Example? (yes, I'm really curious who tried)