Skip to content

OpenAPI: Recommend a standard User-Agent format for REST clients - #17727

Open
rahulsmahadev wants to merge 1 commit into
apache:mainfrom
rahulsmahadev:rest-user-agent-proposal
Open

OpenAPI: Recommend a standard User-Agent format for REST clients#17727
rahulsmahadev wants to merge 1 commit into
apache:mainfrom
rahulsmahadev:rest-user-agent-proposal

Conversation

@rahulsmahadev

@rahulsmahadev rahulsmahadev commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

What

Adds a recommended, consistent User-Agent format to the REST spec so clients identify themselves the same way, and documents that client identification is optional and informational only.

Spec-only proposal

Why

Clients identify themselves inconsistently today, and the most-deployed one doesn't by default:

Client User-Agent X-Client-Version
iceberg-java none by default (opt-in rest.client.user-agent) Apache Iceberg <ver> (commit <sha>) — library version
pyiceberg PyIceberg/<ver> PyIceberg <ver> — library version
iceberg-rust iceberg-rs/<ver> 0.14.1 — REST spec version
iceberg-go GoIceberg/<ver> REST spec version

A catalog operator can't reliably tell what's calling: the Java client sends no User-Agent unless configured, the naming differs across clients, and X-Client-Version carries the library version in two clients and the spec version in the other two. None of it is described in the spec.

A single recommended format gives operators usable telemetry for observability, debugging, and support, and an Iceberg library token that's always present regardless of the embedding engine.

Proposal

Use the standard User-Agent header (RFC 7231): whitespace-separated product/version tokens, most-specific first (engine → integration → Iceberg library → runtime), with a parenthesized comment as an open extension point.

Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala/2.13.16)
  • The Iceberg library token (iceberg-java, pyiceberg, iceberg-rust, iceberg-go) is the piece every client can supply and should always be present.
  • Optional and informational: servers must not reject on missing/malformed, must not use it for auth or trust decisions, and it is not capability negotiation — that's the versioned-endpoints discussion from Core, OpenApi: Add X-Iceberg-Client-Capabilities header #16394, kept deliberately separate.

Scope / follow-ups

This PR is the spec recommendation. If the format lands, client conformance follows as separate PRs:

  • iceberg-java: give rest.client.user-agent a default library token and a way for integrations (Spark/Flink/…) to contribute engine tokens.
  • pyiceberg / iceberg-rust / iceberg-go: emit the same format.

Adds a recommended, consistent User-Agent format to the REST spec so
clients identify themselves the same way, and documents that client
identification is optional and informational only (not authentication,
not capability negotiation).

Spec-only; no behavior change. Client libraries would be updated to emit
this format as follow-ups.
@rahulsmahadev
rahulsmahadev marked this pull request as ready for review August 19, 2026 23:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant