Support bearer-token authentication in BuilderRWBufferFromHTTP

[serxa]

BuilderRWBufferFromHTTP had no way to authenticate with a bearer token: callers spliced an Authorization: Bearer entry into the header list themselves and had to remember not to pass HTTP Basic credentials at the same time, because both occupy the same header. create now takes the credential directly, in three overloads: Basic credentials, a bearer token, or both — with a non-empty token taking precedence, so the either/or rule lives in one place instead of in every caller. create also appends the bearer header to a local copy of the header list rather than mutating the builder, so a builder can be reused without carrying over a stale token.

Every bearer-token call site of the class is migrated to the new overloads:

• HTTPBasedCatalogUtils and UnityCatalog: built the header by hand and passed never-used HTTP Basic credentials alongside; now call create with the token.
• RestCatalog, OneLakeCatalog, BigLakeCatalog: getAuthHeaders now returns an AuthHeaders (a bearer token plus extra headers). The bearer goes to create; only genuine extra headers (a user-supplied auth_header, x-goog-user-project, User-Agent) stay in the header list. OneLakeCatalog's pre-obtained token also moved from a spliced header to the bearer.
• PaimonRestCatalog: the bearer token provider (the dlf request-signing branch keeps its own signed headers).

Out of scope — different transport (plain Poco requests or S3-client headers), not BuilderRWBufferFromHTTP: OpenAIProvider, CloudJWTProvider, ArrowFlight AuthMiddleware, GCS diskSettings.

Changelog category (leave one):

• Not for changelog (changelog entry is not required)

Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):

...

[clickhouse-gh]

Workflow [PR], commit [8543461]

Summary: ✅

• Performance Comparison: Performance dashboard

---

AI Review

Summary

This PR moves bearer-token handling for the Unity and Paimon catalog HTTP paths into BuilderRWBufferFromHTTP::createWithBearerToken, keeps bearer-over-Basic precedence inside the builder, and fixes the OneLake header-validation regression with a focused malformed-token test. The current code paths look correct, but the builder-reuse invariant that already regressed once in this PR still has no focused regression coverage, so I would not approve it yet.

Findings

⚠️ Majors

• [src/IO/ReadWriteBufferFromHTTP.cpp:825] [dismissed by author -- https://github.com/Support bearer-token authentication in BuilderRWBufferFromHTTP #110313#discussion_r3583287166] createWithBearerToken now owns the stale-header fix, but the test added in this PR only covers malformed OneLake tokens, not builder reuse. If a later edit starts mutating http_header_entries again, one reused BuilderRWBufferFromHTTP instance would silently leak the first request's Authorization header into the next one and nothing in the current suite would catch it. Suggested fix: add a small regression test that reuses one builder across two requests and asserts the second request does not carry the first bearer token.

Final Verdict

Status: ⚠️ Request changes

Minimum required action:

• Add focused regression coverage for the builder-reuse case in createWithBearerToken, not just the malformed-token path.

[clickhouse-gh]

LLVM Coverage Report

Metric	Baseline	Current	Δ
Lines	86.20%	86.20%	+0.00%
Functions	92.00%	92.10%	+0.10%
Branches	78.30%	78.30%	+0.00%

Changed lines: Changed C/C++ lines covered: 58/80 (72.50%) · Uncovered code

Full report · Diff report

[clickhouse-gh]

📊 Cloud Performance Report

✅ AI verdict: no_change — no significant changes across 37 queries analysed

The only flagged query is clickbench Q15 (+14.0%, median 215 -> 245 ms), which the deterministic gates already suppressed as within master's current variance band [191, 275] and left as not_sure. CPU time is essentially unchanged (2611 vs 2617 ms), so the extra wall time is cache/IO variance rather than added work. This PR changes only DataLake REST-catalog authentication (bearer token vs HTTP Basic credentials) and the shared HTTP read buffer — code Q15 never runs — so there is no plausible path from the diff to this query. Verdict stands: no real regression here.

clickbench

⚠️ 1 inconclusive

Flagged queries (1 of 43)

	Query	Verdict	Baseline median (ms)	PR median (ms)	Change	q-value	Hint
⚠️	15	not_sure	215	245	+13.9%	<0.0001	cache: CPU is flat (2611 vs 2617 ms) while wall time rose +14.0%, and this PR only touches DataLake catalog HTTP auth — nothing Q15 executes — so the delta reads as page-cache/IO variance, not a PR effect.

_{Change = percent below ×2; the ratio of medians (×N faster/slower) beyond, where percent understates the scale. q-value = BH-FDR adjusted p; smaller is stronger evidence. MIRAI flags a query when q < fdr_q (default 0.10) — the value the verdict is based on.}

tpch_adapted_1_official

🟢 No significant changes

Debug info

• StressHouse run: 1a895a66-35e6-4cba-8301-8f32da9f425a
• MIRAI run: e788884e-51b7-4b8e-96c2-dd22e01ffffb
• PR check IDs:
  • clickbench_528622_1785161446
  • clickbench_528628_1785161446
  • clickbench_528644_1785161446
  • tpch_adapted_1_official_528652_1785161446
  • tpch_adapted_1_official_528677_1785161446
  • tpch_adapted_1_official_528691_1785161446