Hi all, I'd like to propose a recommended User-Agent format for REST catalog clients, so a client identifies itself to a catalog in a consistent, parseable way.
*Today it's inconsistent:*- iceberg-java sends no User-Agent by default (it's opt-in via config). - pyiceberg sends "PyIceberg/<version>", iceberg-rust "iceberg-rs/<version>", iceberg-go "GoIceberg/<version>" basically all different naming. - X-Client-Version carries the library version in Java/Python but the REST spec version in Rust/Go. - None of this is described in the spec. That makes it hard for a catalog operator to tell what's actually calling, which matters for observability, debugging, and support. *Proposal*: use the standard User-Agent header (RFC 7231) i.e. whitespace- separated product/version tokens, most specific first (engine -> integration -> Iceberg library -> runtime), with an optional parenthesized comment for extra context. Example: Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala/2.13.16) The Iceberg library token is the one piece every client can supply, so it should always be present. The header is optional and informational only: servers must not reject on it, must not use it for auth or trust decisions, and it is not a capability negotiation mechanism. *Draft PR with the spec change:https://github.com/apache/iceberg/pull/17727 <https://github.com/apache/iceberg/pull/17727>* If the format looks right, the follow-ups would be conforming the client libraries (java / python / rust / go) to emit it. A few open questions: 1. Should we also reconcile X-Client-Version (library vs spec version across clients), or leave it and treat User-Agent as the canonical identity going forward? 2. Naming: keep the existing library names (PyIceberg, iceberg-rs, GoIceberg) or converge on one scheme (iceberg-<lang>)? 3. Is a separate environment token (e.g. prod/staging) useful, or does that belong in the comment? 4. Any other fields we want to capture ? Feedback welcome. Thanks, Rahul Mahadev (github: rahulsmahadev)
