I agree that this looks like a good addition, so +1 to the proposal. On Thu, Sep 3, 2026 at 1:04 AM Prashant Singh <[email protected]> wrote:
> Thanks for starting the thread Rahul ! > +1 to the proposal > > On Wed, Sep 2, 2026 at 3:37 PM Daniel Weeks <[email protected]> wrote: > >> 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) >>>> >>>
