aws-c-http does not read the entire response body after receiving Connection: Close

[netapp-zwilliam]

Describe the bug

aws mountpoint-s3 receives a Complete Multipart Upload response with a Connection: Close but does not finish reading the body of the Complete Multipart Upload response

See awslabs/mountpoint-s3#1741 for more context.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

From https://datatracker.ietf.org/doc/html/rfc7230#section-6.6

A server that sends a "close" connection option MUST initiate a close
of the connection (see below) after it sends the response containing
"close". The server MUST NOT process any further requests received
on that connection.

A client that receives a "close" connection option MUST cease sending
requests on that connection and close the connection after reading
the response message containing the "close"; if additional pipelined
requests had been sent on the connection, the client SHOULD NOT
assume that they will be processed by the server.

As noted in the spec that

aws-c-http/source/h1_connection.c

Line 1455 in a9745ea

/* RFC-7230 section 6.6

is referring to, it should close the connection after reading the response message. Based on the logs above

Current Behavior

It stops reading data from the final stream, even though based on the spec it should only close the data *after reading the response.

2025-09-17T03:19:46.570758Z TRACE awscrt::http-connection: id=0x7fba040229d0: Incoming message of size 271.
2025-09-17T03:19:46.570767Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming response status: 200 (OK).
2025-09-17T03:19:46.570806Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Date: Wed, 17 Sep 2025 03:19:46 GMT
**2025-09-17T03:19:46.570833Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Connection: CLOSE
2025-09-17T03:19:46.570840Z TRACE awscrt::http-stream: id=0x7fba04045d40: Received 'Connection: close' header. This will be the final stream on this connection.**
2025-09-17T03:19:46.570844Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Server: <redacted>
2025-09-17T03:19:46.570847Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: x-amz-request-id: #############
2025-09-17T03:19:46.570851Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: x-amz-id-2: #########
2025-09-17T03:19:46.570858Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Content-Type: application/xml
2025-09-17T03:19:46.570860Z TRACE awscrt::http-stream: id=0x7fba04045d40: Main header block done.
**2025-09-17T03:19:46.570863Z TRACE awscrt::http-connection: id=0x7fba040229d0: Done reading final stream, no further streams will be read.**
2025-09-17T03:19:46.570869Z DEBUG awscrt::http-stream: id=0x7fba04045d40: Client request complete, response status: 200 (OK).

**2025-09-17T03:19:46.570957Z TRACE awscrt::http-connection: id=0x7fba040229d0: Current incoming stream is now (nil).
2025-09-17T03:19:46.570961Z TRACE awscrt::http-connection: id=0x7fba040229d0: Decoded 232 bytes of message, 39 bytes remain.**
2025-09-17T03:19:46.570963Z ERROR awscrt::http-connection: id=0x7fba040229d0: Cannot process message because connection is shutting down.
2025-09-17T03:19:46.570967Z  INFO awscrt::http-connection: id=0x7fba040229d0: Shutting down connection with error code 2058 (AWS_ERROR_HTTP_CONNECTION_CLOSED).
2025-09-17T03:19:46.570969Z DEBUG awscrt::channel: id=0x7fba04022680: Channel shutdown is already pending, not scheduling another.

Reproduction Steps

Have a server send a response with 200 OK, but without a transfer-encoding: chunked and stream the data after (similar to how AWS complete multipart upload behaves, although S3 usually does chunked transfer-encoding)

https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html

Possible Solution

No response

Additional Information/Context

Looks like #106 reported something similar and it was claimed to be fixed in 0d8d673 but I am not sure if it solved this case specifically

aws-c-http version used

which ever version mount-s3-1.19.0 uses

Compiler and version used

which ever version mount-s3-1.19.0 uses

Operating System and version

Linux Debian 6.1.148-1

[TingDaoK]

2025-09-17T03:19:46.570767Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming response status: 200 (OK).
2025-09-17T03:19:46.570806Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Date: Wed, 17 Sep 2025 03:19:46 GMT
**2025-09-17T03:19:46.570833Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Connection: CLOSE
2025-09-17T03:19:46.570840Z TRACE awscrt::http-stream: id=0x7fba04045d40: Received 'Connection: close' header. This will be the final stream on this connection.**
2025-09-17T03:19:46.570844Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Server: <redacted>
2025-09-17T03:19:46.570847Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: x-amz-request-id: #############
2025-09-17T03:19:46.570851Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: x-amz-id-2: #########
2025-09-17T03:19:46.570858Z TRACE awscrt::http-stream: id=0x7fba04045d40: Incoming header: Content-Type: application/xml

In the log there is no content-length, are we sure we will receive a data?

[TingDaoK]

For HTTP/1.1, if you don't set content-length or transfer-encoding, the response is considered as completed after the headers.
From the log, we processed the headers and found there is no body to read according to the headers and then shutdown the connection after the final response. To me, it shows the correct behavior.

[netapp-zwilliam]

@TingDaoK There is no content-length header sent because the size of the body is not known when the headers are sent.

Point 7 in Section 3.3.3 in RFC7230 (https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.3) says:

7. Otherwise, this is a response message without a declared message
   body length, so the message body length is determined by the
   number of octets received prior to the server closing the
   connection.

So the client should process the bytes until the server closes the connection.

[TingDaoK]

yeah, you are right. Thanks for point it out from the spec!
I'll work on a fix for this case.