Using Expect-100 fails on Transfer Encoding Chunk

[klustria]

Environment Details

• Helidon Version: 4
• Helidon NIMA

---

Problem Description

When using Expect-100 to send Transfer Encoding Chunk, no response is received. When using this handler, the entity is empty:

private static void customHandler(ServerRequest req, ServerResponse res) {
    Headers headers = req.headers();

    requestChunked = headers.contains(Http.HeaderValues.TRANSFER_ENCODING_CHUNKED);
    requestContentLength = headers.contentLength().orElse(NO_CONTENT_LENGTH);
    if (headers.contains(Http.HeaderValues.EXPECT_100)) {
        expects100 = true;
    }

    try (InputStream inputStream = req.content().inputStream();
            OutputStream outputStream = res.outputStream()) {
        // inputStream.transferTo(outputStream);
        byte[] entity = inputStream.readAllBytes();
        System.out.println("Entity is '" + new String(entity) + "'");
        new ByteArrayInputStream(entity).transferTo(outputStream);
    } catch (Exception e) {
        res.status(Http.Status.INTERNAL_SERVER_ERROR_500).send("failed: " + e.getMessage());
    }
}

[danielkec]

req reset need to be done later

[klustria]

Moved request.reset from line 156 of Http1ServerResponse into close() method of BlockingOutputStream and I can see that the entity can now be received properly from the handler. Unfortunately, the web client cannot still accept anything from the response, i.e. HTTP Status and Entity are being read as empty.

[klustria]

Additional observation from the above comment on the webclient side after testing moving request.reset to BlockingOutputStream.close, it seems that there is an extra garbage data being received from the client side. When I add two calls of reader.reabBuffer() while trying to retrieve the response, I see these 2 set of data:

1. Data 1 from reader:
   +--------+-------------------------------------------------+----------------+
   | index| 0 1 2 3 4 5 6 7 8 9 a b c d e f | data|
   +--------+-------------------------------------------------+----------------+
   |00000000| 48 54 |HT |
   +--------+-------------------------------------------------+----------------+
2. Data 2 from reader:
   +--------+-------------------------------------------------+----------------+
   | index| 0 1 2 3 4 5 6 7 8 9 a b c d e f | data|
   +--------+-------------------------------------------------+----------------+
   |00000000| 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d |HTTP/1.1 200 OK.|
   |00000010| 0a 44 61 74 65 3a 20 53 75 6e 2c 20 31 32 20 46 |.Date: Sun, 12 F|
   |00000020| 65 62 20 32 30 32 33 20 32 31 3a 32 30 3a 32 38 |eb 2023 21:20:28|
   |00000030| 20 2d 30 38 30 30 0d 0a 43 6f 6e 6e 65 63 74 69 | -0800..Connecti|
   |00000040| 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 65 0d 0a |on: keep-alive..|
   |00000050| 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e |Transfer-Encodin|
   |00000060| 67 3a 20 63 68 75 6e 6b 65 64 0d 0a 0d 0a |g: chunked.... |
   +--------+-------------------------------------------------+----------------+

The HT or the first data is the reason why the WebClient fails in processing the status. Question is, why is that HT being sent?

[klustria]

The issue I have above where I'm not getting the status is because of this: https://github.com/helidon-io/helidon/blob/main/nima/webserver/webserver/src/main/java/io/helidon/nima/webserver/http1/Http1Connection.java#L58 where there is extra /r/n at the end of Continue 100 response. Prior to the expect-continue-100 recent change, there is only 1 /r/n but in the recent code there are 2. Is that a requirement?

[danielkec]

Afaik it is required by the spec, CRLF at the end of status line and one between optional headers and optional body, when neither optional part is present, required double CRLF is still needed