AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 47 Bitcoin

Merge bitcoin/bitcoin#35735: Add state to HTTPRequest

Public commit record

What the developer wrote

Authored by merge-script

100/100 · Strong
Merge bitcoin/bitcoin#35735: Add state to HTTPRequest

9954aa77280ecd67816e784815c6478a973f6635 http: don't parse any new requests from a client if m_req_busy = true (Matthew Zipkin)
c7db3ae1f907a10748e608cd69899c7586bfc210 test: cover HTTPRequest state machine (Matthew Zipkin)
90676e24ad1aa44346aed586f19ba1c68c477394 Add state to HTTPRequest to avoid duplicate work over I/O cycles (Matthew Zipkin)
507e528e845034583dd21b884e6debb1ff5307e3 http: reuse HTTPHeaders to parse chunked trailer (Matthew Zipkin)
902d8908c94dbe837d712a408d63dcbac634d4c5 http: only read one HTTPRequest at a time per client (Matthew Zipkin)

Pull request description:

This PR reduces the memory consumption of the HTTP Server when reading data from connected clients, and improves performance especially when requests are large (i.e. requiring multiple TCP packets).

In https://github.com/bitcoin/bitcoin/pull/35182 the server copies as much data as it can from the socket into application memory, and then tries to parse as many complete HTTP requests as possible from that data. If a request is discovered to be incomplete, the in-progress request is abandoned. The server tries again on the next I/O cycle to read the same data from the buffer, duplicating work as many times as it takes before the client finishes sending the request (or times out).

This PR implements two improvements to this:
1. Only parse one request at a time from the receive buffer. The server processes requests from each client in series anyway.
2. Add state to `HTTPRequest` so it can be filled with data from the receive buffer over multiple I/O loop iterations without losing progress.

If a client sends large or multiple requests, that data will sit in the kernel's socket buffer instead of the application memory. Eventually the socket buffer will fill up and TCP backpressure will kick in, dropping the TCP window to 0 and blocking the client from sending any more.

A state machine for `HTTPRemoteClient` was [discussed previously](https://github.com/bitcoin/bitcoin/pull/35182#pullrequestreview-4322490068) to control resource consumption. Another nice benefit of this model (for a follow-up PR) will be to insert the RPC authentication check after reading 8kB-limited headers but before the 32MB-limited request body.

ACKs for top commit:
winterrdog:
re-ACK 9954aa77280ecd67816e784815c6478a973f6635
janb84:
re ACK 9954aa77280ecd67816e784815c6478a973f6635
frankomosh:
ACK 9954aa77280ecd67816e784815c6478a973f6635.
fjahr:
ACK 9954aa77280ecd67816e784815c6478a973f6635

Tree-SHA512: b7c913114283fbf1f360b40f6c65a01390a26731bf3b166f460ec260f9206f25d738b3a06887bfa839911c1c6aaf634448181da47a752a9a881aebd907e44868
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This change is a defensive hardening and performance fix for Bitcoin Core's built-in HTTP server. It rewrites how incoming HTTP requests are read so that the server no longer copies an entire large request into memory before processing it. Instead, it reads one request at a time and remembers partial progress across network reads. This reduces memory use and applies size limits more consistently, including to HTTP chunk trailers. The commit is not described by the project as a security fix, but it closes resource-consumption paths that could be abused by a malicious or misbehaving client.

Recommended action

Treat as a worthwhile hardening patch. Reviewers and operators should verify that the new state machine correctly handles edge cases around chunked encoding, pipelining, and abrupt disconnects. No emergency deployment is indicated, but the change should be included in normal release testing.

Security signals we found

01

Memory-consumption reduction: large or multiple requests stay in kernel socket buffer instead of application memory

02

Size-limit enforcement now spans multiple I/O iterations for headers and chunked trailers

03

Single-request-per-client reading prevents queueing of many parsed requests in memory

04

Error handling clears client receive buffer and marks request in Error state to avoid further parsing

05

Functional tests updated to expect backpressure/413 behavior for oversized bodies and chunked transfers

Risk score

Why this scored 47/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.