http: reject Transfer-Encoding other than chunked #36643

pull fametrano wants to merge 1 commits into bitcoin:master from fametrano:http-transfer-encoding changing 4 files +86 −3
  1. fametrano commented at 6:51 AM on October 24, 2026: none

    The HTTP server frames a request body by Content-Length when its Transfer-Encoding is not exactly chunked.

    LoadBody() reads only the first Transfer-Encoding header. With gzip, chunked, gzip, or identity followed by a second chunked header, the body is read by Content-Length, or not at all. RFC 9112 section 6.3 requires a 400 when chunked is not the final coding. The server supports no other coding. I now accept only a single chunked, across all Transfer-Encoding headers, and answer anything else with a 400. Unlike #36243, I still allow Content-Length next to chunked, as the existing interface_http.py test expects. The new rejection cases in httpserver_tests and interface_http.py fail on master and pass with this change. The framing check in the http_request fuzz target needed the same change, or it fails on Transfer-Encoding: chunked, .

    This is one of several PRs from a large audit of Bitcoin Core that I did with the help of LLM tools. The audit produced its evidence all at once, which is why the PRs arrive together. I understand each change fully and will answer review questions myself.

  2. http: reject Transfer-Encoding other than chunked
    A request with "Transfer-Encoding: gzip" or "chunked, gzip" is framed
    by Content-Length, or read as having no body. So is a request whose
    first Transfer-Encoding header is not "chunked". RFC 9112 section 6.3
    requires a 400 when chunked is not the final coding. The server
    supports no other coding.
    
    LoadBody() now accepts only a single "chunked", across all
    Transfer-Encoding headers. Anything else throws, which gives a 400 and
    closes the connection. I added unit and functional tests, and updated
    the http_request fuzz target to match.
    458f88f58e
  3. DrahtBot added the label RPC/REST/ZMQ on Oct 24, 2026
  4. DrahtBot commented at 6:52 AM on October 24, 2026: contributor

    <!--e57a25ab6845829454e8d69fc972939a-->

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    <!--006a51241073e994b41acfe9ec718e94-->

    External sites

    <!--021abf342d371248e50ceaed478a90ca-->

    Reviews

    See the guideline and AI policy for information on the review process.

    Type Reviewers
    Concept NACK pinheadmz

    If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

    <!--5faf32d7da4f0f540f40219e4f7537a3-->

  5. winterrdog commented at 11:08 AM on October 24, 2026: contributor

    With gzip, chunked, gzip, or identity followed by a second chunked header, the body is read by Content-Length, or not at all.

    i want to understand something. under what circumstances would a user realistically run into this scenario, given that bitcoin-cli does not send these kinds of requests ?

  6. fametrano commented at 9:46 PM on October 24, 2026: none

    Not with bitcoin-cli. These headers can come from other HTTP clients, or from a proxy in front of the RPC port. If the proxy and the server disagree on where a body ends, the server can read part of one request as the next. RFC 9112 section 6.3 asks for a 400 when chunked is not the final coding. This change sends a 400 for anything other than a single chunked.

  7. pinheadmz commented at 7:34 PM on October 26, 2026: member

    NACK

    I don't see any urgent value in this change. If a user is running a proxy in front of bitcoin that re-uses backend connections and they send (over the assume-trusted connection) unsupported HTTP headers and then their bitcoin core experience suffers, we can reconsider that use case.

  8. sedited commented at 7:39 PM on October 26, 2026: contributor

    Closing given the responses here.

  9. sedited closed this on Oct 26, 2026


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-10-30 15:51 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me