Hey Rahul, Thanks for the proposal. Minor comments on the spec, but overall looks great.
On Wed, Sep 2, 2026 at 3:01 PM Ryan Blue <[email protected]> wrote: > This looks like a good proposal to me. Thanks, Rahul. > > On Wed, Sep 2, 2026 at 9:05 AM Alex Dutra <[email protected]> wrote: > >> Hi Rahul, >> >> I really like your proposal. Some time ago, I attempted to identify >> clients in Polaris by analyzing their User-Agent and X-Client-Version >> headers, but I quickly discovered that this approach was far more >> complicated and unreliable than I had expected [1]. I think the >> standardization that you are proposing here will finally make it >> doable. >> >> Thanks, >> Alex >> >> [1]: https://github.com/apache/polaris/pull/4236 >> >> On Tue, Sep 1, 2026 at 6:26 PM rahul mahadev <[email protected]> >> wrote: >> > >> > 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 >> > >> > 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) >> >
