Skip to content

Size singleton bitcoind json-rpc and stream http responses. - #1149

Closed
eynhaender wants to merge 1 commit into
libbitcoin:masterfrom
eynhaender:fix/bitcoind-content-length
Closed

eynhaender wants to merge 1 commit into
libbitcoin:masterfrom
eynhaender:fix/bitcoind-content-length

Conversation

@eynhaender

Copy link
Copy Markdown
Member

Every http json-rpc response was sent with chunked transfer coding, which is conformant for http/1.1 (rfc9112 6.1). bitcoind never chunks, and some of its clients (e.g. fulcrum) reject a response without content-length, contrary to rfc9112. To tolerate them, a non-batch response is serialized up front and sent with content-length. Batch responses remain chunked.

A stream response has a known size and is now sent with content-length instead of chunked.

Every http json-rpc response was sent with chunked transfer coding, which
is conformant for http/1.1 (rfc9112 6.1). bitcoind never chunks, and some
of its clients (e.g. fulcrum) reject a response without content-length,
contrary to rfc9112. To tolerate them, a non-batch response is serialized
up front and sent with content-length. Batch responses remain chunked.

A stream response has a known size and is now sent with content-length
instead of chunked.
@evoskuil

Copy link
Copy Markdown
Member

Added this to the backlog as a maybe, but I'm not convinced it's a good idea to allow bad clients to break our spec and perf, especially if the example is Fulcrum, which would never be synced against bs. Also the implementation needs to vary from this, so closing for now. Thanks

@evoskuil evoskuil closed this Nov 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants