Skip to content

fix(beacon): forward Content-Type header from upstream responses#806

Merged
tonatoz merged 1 commit intomasterfrom
fix/beacon-forward-content-type
Mar 20, 2026
Merged

fix(beacon): forward Content-Type header from upstream responses#806
tonatoz merged 1 commit intomasterfrom
fix/beacon-forward-content-type

Conversation

@tonatoz
Copy link
Copy Markdown
Contributor

@tonatoz tonatoz commented Mar 19, 2026

Summary

  • Add Content-Type to beacon chain response headers whitelist in BeaconChainSpecific.getResponseHeadersToForward()
  • Without this, RestHttpReader.extractResponseHeaders() drops the Content-Type from upstream beacon nodes
  • dproxy then hardcodes application/json for all REST responses, causing SSZ binary data to be mislabeled

Problem

GET /eth/v2/debug/beacon/states/{slot} with Accept: application/octet-stream returns SSZ binary but Content-Type: application/json. Clients fail with:

SyntaxError: Unexpected token ... is not valid JSON

Observed from multiple providers (zero1node, nodesguru, kukisglobal). Actively used endpoint (~80+ req/hour).

Root cause

BeaconChainSpecific.getResponseHeadersToForward() only whitelisted Eth-Consensus-* headers. Content-Type was filtered out by RestHttpReader.extractResponseHeaders() before reaching the gRPC response_headers field.

Companion PR

drpcorg/dproxy#2348 — dproxy side: use upstream Content-Type when present instead of hardcoded application/json

Add Content-Type to the beacon chain response headers whitelist.
Without this, REST endpoints returning SSZ binary data (e.g.
/eth/v2/debug/beacon/states) are mislabeled as application/json
by dproxy, breaking client-side parsing.

Companion fix: drpcorg/dproxy#2348
@tonatoz tonatoz merged commit cbf6ae9 into master Mar 20, 2026
1 check passed
@tonatoz tonatoz deleted the fix/beacon-forward-content-type branch March 20, 2026 08:02
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