+1 to this proposal On Wed, Sep 9, 2026 at 1:25 AM Yufei Gu <[email protected]> wrote:
> I agree with Alex. Downstream projects are currently struggling to > build proper parsers without standardization, and > https://github.com/apache/polaris/pull/4236 is a good example. > > +1 on the proposal. > > Best, > Yufei > > On Sun, Sep 6, 2026 at 10:58 PM Eduard Tudenhöfner > <[email protected]> wrote: > > > > 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) >
