JuliusBrussee/caveman · error

clickhouse response exceeds %d byte limit

Error message

clickhouse response exceeds %d byte limit

What it means

The ClickHouse HTTP response body exceeded the configured byte ceiling; the helper reads maxBytes+1 to distinguish over-limit from exact-limit and fails closed before parsing or logging attacker-controlled content. It signals either a misbehaving endpoint or a limit set below legitimate payload size.

Source

Thrown at shared/platform/chhttp/chhttp.go:58

const (
	defaultInsertTimeoutMS = 5000
	defaultQueryTimeoutMS  = 30000
)

// ReadBodyBounded reads an HTTP response/error body with a hard byte ceiling.
// It deliberately reads one byte beyond the limit so callers can distinguish a
// truncated body from an exact-limit body and fail closed before parsing or
// logging attacker-controlled content.
func ReadBodyBounded(r io.Reader, maxBytes int64) ([]byte, error) {
	if maxBytes <= 0 {
		return nil, fmt.Errorf("clickhouse response byte limit must be positive")
	}
	data, err := io.ReadAll(io.LimitReader(r, maxBytes+1))
	if err != nil {
		return nil, err
	}
	if int64(len(data)) > maxBytes {
		return nil, fmt.Errorf("clickhouse response exceeds %d byte limit", maxBytes)
	}
	return data, nil
}

// The TLS knobs. All three are unset by default, in which case the clients keep
// stock net/http behaviour: system roots, hostname verified against the URL host.
const (
	// serverNameEnv overrides tls.Config.ServerName. This is the managed-
	// ClickHouse cutover case: the private .internal DNS record is dialled while
	// the deployment's certificate carries only *.dtwh SANs, so verification must
	// run against the name the certificate actually holds. Chain AND hostname
	// verification stay fully enforced — only the name being matched changes.
	serverNameEnv = "CLICKHOUSE_TLS_SERVER_NAME"
	// caFileEnv is a path to a PEM bundle APPENDED to the system roots (a private
	// CA is trusted in addition to, never instead of, the public ones).
	caFileEnv = "CLICKHOUSE_TLS_CA_FILE"
	// skipVerifyEnv disables chain and hostname verification. Production refuses
	// it outright; outside production it is honoured with a startup warning.

View on GitHub (pinned to 766dce6b13)

Solutions

  1. Raise the response byte limit if legitimate payloads are larger
  2. Investigate the endpoint if responses are unexpectedly huge — it may be returning an error page or garbage
Defensive patterns

Strategy: fallback

When it happens

Trigger: Thrown at shared/platform/chhttp/chhttp.go:58 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of JuliusBrussee/caveman@766dce6b13 (2026-08-18). Data as JSON: /api/errors/be2a81dc81f2866c. Report an issue: GitHub.