`bitreq`: Add RFC 9112 compliance test vectors by tnull · Pull Request #660 · rust-bitcoin/corepc

tnull · 2026-07-13T05:57:45Z

In #659 we recently discovered that we aren't fully compliant with RFC 9112 / HTTP 1.1.

As a first step of mitigation, we here add some test vectors that cover the central points. We opted to mark the (33!) failing checks as ignored, so we can revisit and fix them in following PRs (instead of cramming everything into one PR).

Response/cache poisoning: Extra unsolicited bytes can be accepted as the next response (§§6.3, 9.2).
Request smuggling/injection: Custom methods and headers allow CR/control-character injection; conflicting Host fields are transmitted (§§2.2–5).
Ambiguous message framing: Requests can contain both Content-Length and Transfer-Encoding; conflicting response lengths are accepted (§§6.1–6.3).
Incomplete responses accepted: Premature EOF, missing terminal zero chunks, and truncated header sections can be treated as complete (§8).
Invalid response syntax accepted: Malformed status lines, bare CR, whitespace-prefixed fields, and obsolete line folding are not handled as required (§§2–5).
Incorrect transfer-coding handling: Coding lists such as gzip, chunked, HTTP/1.0 Transfer-Encoding, and trailers are mishandled (§§6–7).
Broken connection semantics: HTTP/1.1 persistence incorrectly requires keep-alive; sent Connection: close can be ignored; tokenized options are not parsed correctly (§§9.3, 9.6).
CONNECT noncompliance: CONNECT uses the wrong request-target, omits the required proxy Host, and treats successful CONNECT responses as ordinary bodies (§§3.2, 6.3).

And more minor:

Consume 1xx informational responses until the final response.
Treat clean async EOF as successful for valid close-delimited responses.
Retry unanswered pipelined requests without immediately re-pipelining.

Exercise the HTTP/1.1 wire grammar so request generation and response parsing gaps are visible before behavior is changed. Co-Authored-By: HAL 9000

Cover response length and chunk decoding rules so incomplete or ambiguous messages cannot pass unnoticed. Co-Authored-By: HAL 9000

Cover persistence, closure, and pipelining rules so connection reuse can be corrected against explicit expectations. Refs: rust-bitcoin#659 Co-Authored-By: HAL 9000

TheBlueMatt

thanks!

TheBlueMatt · 2026-07-17T12:18:56Z

+}
+
+#[test]
+#[ignore = "TODO: reject bare CR in request protocol elements (RFC 9112 Section 2.2)"]


Do we actually intend to fix all these? I'm happy to see them fixed if we care, but its not clear to me that we do/should, at which point adding tests for them is just noise.

Yes, I think we should. #661 is the start, but I intend to tackle these bit-by-bit in follow-ups.

FWIW I don't think we should bother trying to be super strict on what the calling code passes. In this case specifically where the request is invalid, I think we should just accept it. The only exception would be if the request is bad in a way that will break our request code, ie if it might make two requests because it adds a \r\n\r\nGET... or something similar. I think that basically just means rejecting \r\ns and maybe rejecting standalone \r and \ns

TheBlueMatt

I skimmed about the first half of these. I think most of them its not worth enforcing - stuff where the server or client are maybe a bit confused but we can parse the resulting stream fine I really don't think we should add code to be strict on the RFC for.

TheBlueMatt · 2026-07-22T18:24:19Z

+}
+
+#[test]
+#[ignore = "TODO: reject bare CR in request protocol elements (RFC 9112 Section 2.2)"]


FWIW I don't think we should bother trying to be super strict on what the calling code passes. In this case specifically where the request is invalid, I think we should just accept it. The only exception would be if the request is bad in a way that will break our request code, ie if it might make two requests because it adds a \r\n\r\nGET... or something similar. I think that basically just means rejecting \r\ns and maybe rejecting standalone \r and \ns

TheBlueMatt · 2026-07-22T18:24:28Z

+}
+
+#[test]
+#[ignore = "TODO: reject invalid request field names (RFC 9112 Sections 2.2 and 5)"]


I don't think we should bother rejecting this.

TheBlueMatt · 2026-07-22T18:28:06Z

+}
+
+#[test]
+#[ignore = "TODO: reject conflicting Host fields (RFC 9112 Section 3.2)"]


I don't think we should worry about stuff like this.

TheBlueMatt · 2026-07-22T18:29:38Z

+
+#[test]
+#[ignore = "TODO: validate response status-line grammar (RFC 9112 Sections 2.3 and 4)"]
+fn section_4_invalid_status_lines_are_rejected() {


I don't think we should enforce this.

TheBlueMatt · 2026-07-22T18:30:35Z

+}
+
+#[test]
+#[ignore = "TODO: reject or ignore whitespace-prefixed fields (RFC 9112 Section 2.2)"]


I don't see why we should enforce this.

TheBlueMatt · 2026-07-22T18:34:47Z

+#[test]
+#[ignore = "TODO: reject repeated chunked transfer coding (RFC 9112 Section 6.1)"]
+fn section_6_1_sender_rejects_repeated_chunked_coding() {
+    // RFC 9112 Section 6.1: a sender MUST NOT apply chunked transfer coding more than once.


I don't see why we should reject this.

TheBlueMatt · 2026-07-22T18:42:53Z

+}
+
+#[test]
+#[ignore = "TODO: exclude chunked from TE requests (RFC 9112 Section 7.4)"]


Let's please not add parsing of random client headers just to enforce them.

TheBlueMatt · 2026-07-22T18:43:00Z

+}
+
+#[test]
+#[ignore = "TODO: add the TE connection option when sending TE (RFC 9112 Section 7.4)"]


TheBlueMatt · 2026-07-22T18:43:26Z

+#[ignore = "TODO: treat successful CONNECT responses as tunnels (RFC 9112 Section 6.3)"]
+fn section_6_3_successful_connect_ignores_framing_fields() {
+    // RFC 9112 Section 6.3: a client receiving a successful CONNECT response MUST ignore
+    // Content-Length and Transfer-Encoding because the connection becomes a tunnel.


Are we even going to support parsing this? Its not clear how to parse this if we're pipelining and if a proxy is this broken kinda who cares?

TheBlueMatt · 2026-07-22T18:44:58Z

+#[ignore = "TODO: reject Transfer-Encoding in HTTP/1.0 responses (RFC 9112 Section 6.1)"]
+fn section_6_1_http_1_0_transfer_encoding_is_faulty() {
+    // RFC 9112 Section 6.1: a client receiving Transfer-Encoding in HTTP/1.0 MUST treat framing as
+    // faulty and close the connection.


Why is it worth our time to enforce this?

tnull added 3 commits July 11, 2026 15:21

Test RFC 9112 message syntax

41aee53

Exercise the HTTP/1.1 wire grammar so request generation and response parsing gaps are visible before behavior is changed. Co-Authored-By: HAL 9000

Test RFC 9112 message framing

6eee839

Cover response length and chunk decoding rules so incomplete or ambiguous messages cannot pass unnoticed. Co-Authored-By: HAL 9000

Test RFC 9112 connection handling

3390f88

Cover persistence, closure, and pipelining rules so connection reuse can be corrected against explicit expectations. Refs: rust-bitcoin#659 Co-Authored-By: HAL 9000

tnull requested review from TheBlueMatt and oleonardolima as code owners July 13, 2026 05:57

github-actions Bot added the C-bitreq label Jul 13, 2026

tnull mentioned this pull request Jul 13, 2026

bitreq: Fix connection persistence, pool refresh #661

Open

TheBlueMatt reviewed Jul 17, 2026

View reviewed changes

tnull requested a review from TheBlueMatt July 20, 2026 07:51

TheBlueMatt reviewed Jul 22, 2026

View reviewed changes

Uh oh!

Conversation

tnull commented Jul 13, 2026

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants