Implement HTTP 103 Early Hints (RFC 8297) interim responses

[BalusC]

Add Response.sendEarlyHints() to send 103 Early Hints interim responses over HTTP/1.1, HTTP/2 and AJP. An interim response carries the headers currently set on the response (e.g. Link preload hints), does not commit the response, and may be sent multiple times before the final response. Inspired by Jetty 12 and Tomcat 12.

Prerequisite for a green build of eclipse-ee4j/mojarra#5748.

Core (modules/http)

• New HttpStatus.EARLY_HINTS_103.
• HttpResponsePacket holds a transient interimStatus separate from the final status; serializing an interim response leaves the final status untouched.
• HttpCodecFilter serializes the interim status line and headers without marking the headers serialized, so they re-emit with the final response.
• HttpServerFilter.encodeInitialLine refactored to share a single private helper with a (packet, status) overload — preserves CustomReasonPhrase on the final response only.
• 100-Continue and 1xx interim responses now share a single interimStatus mechanism (removed setAcknowledgement/isAcknowledgement/acknowledged from HttpResponsePacket; the four parallel isAcknowledgement branches in HTTP/1.1, AJP and HTTP/2 codecs collapse into the interim branch). OutputBuffer.acknowledge() and writeInterimResponse() collapse into the latter.
• HttpServerFilter no longer runs prepareResponse (which injects Date/Content-Type/Content-Length) on interim packets — those mutations belong to the final response.

HTTP/2 (modules/http2)

• DefaultOutputSink emits the interim as a HEADERS frame (END_HEADERS, no END_STREAM) without committing the stream.
• Http2ClientFilter accepts inbound interim 1xx responses instead of failing with PROTOCOL_ERROR.
• DecoderUtils.finalizeKnownHeader had a missing return on case "expect": (and case "te":) causing every HTTP/2 Expect: 100-continue request to be rejected at decode time — fixed. HTTP/2 100-Continue now works end-to-end via the unified interim mechanism.
• HttpServerFilter#prepareRequest uses the new Protocol#isAtLeast(HTTP_1_1) for the legacy-protocol check.

AJP (modules/http-ajp)

• AjpHandlerFilter and AjpMessageUtils encode interim responses as SEND_HEADERS packets without committing — the existing 100-Continue mechanism generalised. Tomcat NO-OPs early hints over AJP; we implement because the AJP13 protocol does not forbid multiple SEND_HEADERS packets, and forwarding is the upstream connector's concern.

Servlet (modules/http-servlet)

• HttpServletResponseImpl.sendEarlyHints() (Servlet 6.2). The Servlet 6.2 spec signature does not declare IOException; the (effectively unreachable) async write path's checked exception is logged and swallowed — matches glassfish web-core's ResponseFacade.
• ServletHandler.AckActionImpl.acknowledge() no longer leaks status 100 onto the final response after the unification (regression test added).
• jakarta.servlet-api bumped 6.1.0 → 6.2.0-M2.

Tests

• EarlyHintsTest (HTTP/1.1), Http2EarlyHintsTest, AjpEarlyHintsTest — interim 103 carries Link, final response still has it.
• Http2ContinueTest — HTTP/2 100-Continue end-to-end.
• ServletHttpContinueTest regression for the auto-ack leak.
• HttpContinueTest, BasicAjpTest.test100ContinuePost, ServletHttpContinueTest all still green after unification.

[carryel]

Although Servlet spec 6.2 has not been released yet, how about adding it to HttpServletResponseImpl for the future?

Reference) https://github.com/jakartaee/servlet/pull/672/files

For example, it is as follows:

    /**
     * Sends a 103 response to the client using the current response headers. This method does not commit the response and
     * may be called multiple times before the response is committed. The current response headers may include some headers
     * that have been added automatcially by the container.
     * <p>
     * This method has no effect if called after the response has been committed.
     *
     * @since Servlet 6.2
     */
    public void sendEarlyHints() {
        if (response == null) {
            throw new IllegalStateException("Null response object");
        }
        return response.sendEarlyHints();
    }

[carryel]

I think the AJP Protocol also needs to be modified. It would be good if you referred to the section below and considered it in a similar manner.

glassfish-grizzly/modules/http-ajp/src/main/java/org/glassfish/grizzly/http/ajp/AjpHandlerFilter.java

Lines 213 to 218 in e5c322d

	if (httpResponsePacket.isAcknowledgement()) {
	encodedBuffer.trim();
	httpResponsePacket.acknowledged();
	return encodedBuffer; // DO NOT MARK COMMITTED
	}

glassfish-grizzly/modules/http-ajp/src/main/java/org/glassfish/grizzly/http/ajp/AjpMessageUtils.java

Lines 385 to 389 in e5c322d

	if (httpResponsePacket.isAcknowledgement()) {
	// If it's acknoledgment packet - don't encode the headers
	// Serialize 0 num_headers
	encodedBuffer = putShort(mm, encodedBuffer, 0);
	} else {

[BalusC]

Great feedback. Let me take a look.

[BalusC]

AJP is going to be more work than anticipated because there is no foundation and it's even not implemented in Tomcat so it cannot be used as reference.

[BalusC]

@carryel: all your feedback has been addressed. PR description is also updated.

[BalusC]

Thank you for merging. What's the approximate release date for 5.0.2?

[carryel]

What's the approximate release date for 5.0.2?

As far as I know, Grizzly does not release updates regularly.

I believe that if there is a need or if a sufficient number of features are gathered, it will be possible to release updates at any time upon request.

[OndroMih]

We will release Grizzly 5.0.2 soon, there's also an important fix pending