Thank you for the proposal. I’m definitely interested in a unified user agent. I think the proposed format looks good.
My only point I’m unsure about is what we would do if the current approach needs to change or if we want to add more granular information. (engine -> integration -> Iceberg library -> runtime) Would we want ( {Optional} Vendor -> Engine -> Integration -> Iceberg library language -> Runtime) or maybe (… -> Runtime -> {Optional} Vendor) since Vendor isn’t always going to be appropriate.
Best Regards, Kurtis Wright +1 to this proposal
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)
|
