100-Continue is not correctly responded for chunked requests

[hs536]

Grizzly implements handling for the Expect: 100-Continue header; however, this handling fails for chunked requests. While a 100-Continue response should be sent upon completion of parsing the header chunk containing Expect: 100-Continue, Grizzly does not reach the following handler method and delays the response until the first byte of the subsequent body is received.

grizzly/modules/http-server/src/main/java/org/glassfish/grizzly/http/server/HttpHandler.java

Lines 354 to 364 in c3dcb70

	protected boolean sendAcknowledgment(final Request request, final Response response) throws IOException {
	if ("100-continue".equalsIgnoreCase(request.getHeader(Header.Expect))) {
	response.setStatus(HttpStatus.CONINTUE_100);
	response.sendAcknowledgement();
	return true;
	} else {
	response.setStatus(HttpStatus.EXPECTATION_FAILED_417);
	return false;
	}
	}

This behavior can cause timeouts, particularly when requests are proxied through Apache 2.4.x. Apache 2.4.x, when a request includes the Expect: 100-Continue header, waits for a 100-Continue response from the backend server before sending the request body. This creates a deadlock between Grizzly and Apache, resulting in request timeouts.

While this behavior can be worked around by setting Proxy100Continue Off in Apache, this prevents the client from verifying server acceptance of the data before transmission.

[carryel]

I have a question to make it clearer.

Does this issue refer to chunked transfer coding? For example, I wonder if it refers to a request that includes a Transfer-Encoding: chunked header.

When I reviewed Grizzly source codes related to 100-continue support,

• A request that includes a Content-Length header, not chunked transfer coding
• However, if the content body has not been transmitted yet

If the above is satisfied, it is expected to work well.

If it is chunked transfer coding, it does not seem easy to support this feature.
Also, when I looked at the spec document, the scenario of using chunked transfer coding and Expect: 100-continue together seemed a bit unclear.

If you have any reference materials or scenarios, I will think about it further.

[hs536]

Does this issue refer to chunked transfer coding? For example, I wonder if it refers to a request that includes a Transfer-Encoding: chunked header.

Yes. I've uploaded the simple server application and more detailed reproduction instructions below.
https://github.com/hs536/grizzly-2222

[carryel]

With the information you provided, I was able to reproduce it successfully.

As expected, when there is content-length, 100-continue works well,
and in the case of chunked transfer coding, I found that it waits for the length to be included in the body before processing 100-continue.

In the case of Apache web server, when the work-around option above is used, the corresponding header is not delivered to Grizzly, and the web server itself processes 100-continue. In the case of nginx, I also confirmed that the web server itself processes it.

I will take a closer look at how to handle cases such as chunked transfer coding when Expect: 100-Continue is delivered to the backend application server, such as Grizzly + Apache web server.

[carryel]

@hs536 I submitted a PR.
I also checked your reproduction project(https://github.com/hs536/grizzly-2222) with the patched version and it worked fine.
Could you please check it?
Since the jar or class file is not attached at github issue, I think you will have to apply it yourself.

The patch file is only org/glassfish/grizzly/http/HttpServerFilter.java.