You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by "rahulsmahadev (via GitHub)" <gi...@apache.org> on 2026/08/19 20:57:29 UTC

[PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

rahulsmahadev opened a new pull request, #17727:
URL: https://github.com/apache/iceberg/pull/17727

   ## What
   
   Adds a recommended, consistent `User-Agent` format to the REST spec so clients identify themselves the same way, and documents that client identification is optional and informational only.
   
   Spec-only proposal — no behavior change. Client libraries would be updated to emit this format in follow-ups (see Scope).
   
   ## Why
   
   Clients identify themselves inconsistently today, and the most-deployed one doesn't by default:
   
   | Client | `User-Agent` | `X-Client-Version` |
   | --- | --- | --- |
   | iceberg-java | none by default (opt-in `rest.client.user-agent`) | `Apache Iceberg <ver> (commit <sha>)` — library version |
   | pyiceberg | `PyIceberg/<ver>` | `PyIceberg <ver>` — library version |
   | iceberg-rust | `iceberg-rs/<ver>` | `0.14.1` — REST spec version |
   | iceberg-go | `GoIceberg/<ver>` | REST spec version |
   
   A catalog operator can't reliably tell what's calling: the Java client sends no `User-Agent` unless configured, the naming differs across clients, and `X-Client-Version` carries the library version in two clients and the spec version in the other two. None of it is described in the spec.
   
   A single recommended format gives operators usable telemetry for observability, debugging, and support, and an Iceberg library token that's always present regardless of the embedding engine.
   
   ## Proposal
   
   Use the standard `User-Agent` header (RFC 7231): whitespace-separated `product/version` tokens, most-specific first (engine → integration → Iceberg library → runtime), with a parenthesized comment as an open extension point.
   
   ```
   Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala/2.13.16)
   ```
   
   - The Iceberg library token (`iceberg-java`, `pyiceberg`, `iceberg-rust`, `iceberg-go`) is the piece every client can supply and should always be present.
   - Optional and informational: servers must not reject on missing/malformed, must not use it for auth or trust decisions, and it is **not** capability negotiation — that's the versioned-endpoints discussion from #16394, kept deliberately separate.
   
   ## Scope / follow-ups
   
   This PR is the spec recommendation. If the format lands, client conformance follows as separate PRs:
   
   - iceberg-java: give `rest.client.user-agent` a default library token and a way for integrations (Spark/Flink/…) to contribute engine tokens.
   - pyiceberg / iceberg-rust / iceberg-go: emit the same format.
   
   ## Open questions
   
   1. Should this also reconcile `X-Client-Version` (library vs. spec version across clients), or leave it as-is and treat `User-Agent` as the canonical identity going forward?
   2. Naming: keep existing library names (`PyIceberg`, `iceberg-rs`, `GoIceberg`) or converge on one scheme (`iceberg-<lang>`)?
   3. Is a separate environment token (e.g. prod/staging) wanted, or does that belong in the comment?
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "danielcweeks (via GitHub)" <gi...@apache.org>.
danielcweeks commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r3919301812


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Recommended header for a client to identify itself to the catalog. It
+        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+        5.5.3): a whitespace-separated list of `product/version` tokens,
+        optionally followed by a parenthesized comment.
+
+
+        Tokens SHOULD be ordered from the outermost component to the innermost,
+        so the most specific caller appears first: the engine or application,
+        then any integration or connector, then the Iceberg client library,
+        then the language runtime. The Iceberg client library token is the one
+        component every client can supply and SHOULD always be present.
+        Recommended library tokens are `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, and `iceberg-go`.
+
+
+        The trailing parenthesized comment is an open extension point for
+        additional, lower-value context such as build identifiers, the HTTP
+        library, or the operating system, given as bare tokens or `key=value`
+        pairs separated by `; `. Servers SHOULD treat the comment as free-form
+        and MUST NOT depend on its contents.
+
+
+        Examples:
+
+
+        `pyiceberg/0.11.0 (cpython/3.11.4)` — a client library used directly.
+
+
+        `Trino/438 iceberg-java/1.9.0 (jvm/17.0.9)` — an engine embedding the
+        Iceberg Java library.
+
+
+        `Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala/2.13.16)` —
+        an engine with a connector layer on top of the library.
+
+
+        This header is optional and informational; see "Client Identification"
+        in the API description for the rules that apply to all client-identity
+        headers. Servers MUST NOT reject a request based on its presence,

Review Comment:
   > Servers MUST NOT reject . . . 
   
   I don't agree with this statement.  Not because I'm concerned that implementations would gate maliciously, but rather there may be versions that have critical bugs or vulnerabilities and the catalog should be able to reject certain operations for those clients.
   
   For example, if we know a specific version of engine or library will produce corrupt statistics, we should be able to reject commits by those clients.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4290410343


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,37 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable

Review Comment:
    RFC 7231 has been replaced by RFC 9110, where User-Agent is Section 10.1.5.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4225800422


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,33 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable
+    format gives catalog operators usable telemetry for observability,
+    debugging, and support across the many engines and libraries that speak
+    this protocol. The recommended format is defined by the `User-Agent`
+    parameter in the components section of this document.
+
+    Client identification is advisory:
+
+    - Servers SHOULD NOT reject a request only because the header is absent,
+      incomplete, or malformed. Clients that do not send it remain fully
+      functional.
+    - The value is client-asserted and can be spoofed, so servers MUST NOT use
+      it for authentication or authorization.
+    - It is not a capability negotiation mechanism: clients do not advertise
+      the protocol features they support through this header, and servers do
+      not use it to select features or vary response content.
+    - Servers MAY refuse specific operations for client versions known to be

Review Comment:
   updated it, it should be clearer now



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "sungwy (via GitHub)" <gi...@apache.org>.
sungwy commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-5998432313

   Thanks for the PR @rahulsmahadev - it looks like the CI is failing due to CVE-2026-68497 (https://github.com/apache/iceberg/pull/18318)
   
   Could you please rebase it on main and let the CI run one more time?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6205953108

   Friendly ping for review @manuzhang @singhpk234 @openinx 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4290656768


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2200,70 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the

Review Comment:
   It's not clear how a server can always identify the library and its version when there are multiple tokens from custom implementations.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4225799167


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2196,64 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the
+        outermost component to the innermost, so the most specific caller
+        appears first: the engine or application, then any integration or
+        connector, then the Iceberg library.
+
+
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. These

Review Comment:
   added



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "danielcweeks (via GitHub)" <gi...@apache.org>.
danielcweeks commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4138606844


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2186,64 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the
+        outermost component to the innermost, so the most specific caller
+        appears first: the engine or application, then any integration or
+        connector, then the Iceberg library.
+
+
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. These
+        context items SHOULD be grouped into a single comment placed after all
+        product tokens rather than interleaved between them, and separated by
+        `; ` when there is more than one, for example `(jvm 17.0.9; ubuntu
+        26.04)`. Everything inside the parentheses is a free-form comment
+        rather than a `product/version` token; servers SHOULD treat it as
+        opaque and MUST NOT depend on its contents.
+
+
+        Examples:
+
+
+        `pyiceberg/0.11.0 (cpython 3.11.4)` — a client library used directly.
+
+
+        `Trino/438 iceberg-java/1.9.0 (jvm 17.0.9)` — an engine embedding the
+        Iceberg Java library.
+
+
+        `Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala 2.13.16)` —
+        an engine with a connector layer on top of the library.
+
+
+        The header is advisory: a server MUST NOT reject a request only because
+        it is absent, incomplete, or malformed. See "Client Identification" in
+        the API description for the full rules that apply to client-identity
+        headers.

Review Comment:
   ```suggestion
           The header is advisory: a server SHOULD NOT reject a request only because
           it is absent, incomplete, or malformed. See "Client Identification" in
           the API description for the full rules that apply to client-identity
           headers.
   ```
   
   We need to be careful to not levy unnecessary requirements on the implementing service.  `MUST NOT` is a strict requirement and I don't think we need to restrict this behavior specifically.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6484672153

   LGTM. Thanks for the PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6509975276

   Thanks @openinx and @manuzhang! @singhpk234, could you take a look when you get a chance?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6428410282

   @manuzhang addressed your comments, PTAL


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4356371896


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,37 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable

Review Comment:
   Updated to RFC 9110, Section 10.1.5.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4356383975


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,37 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable
+    format gives catalog operators usable telemetry for observability,
+    debugging, and support across the many engines and libraries that speak
+    this protocol. The recommended format is defined by the `User-Agent`
+    parameter in the components section of this document.
+
+    Client identification is advisory:
+
+    - Servers SHOULD NOT reject a request only because the header is absent,
+      incomplete, or malformed. Clients that do not send it remain fully
+      functional.
+    - The value is client-asserted and can be spoofed, so servers MUST NOT use
+      it for authentication or authorization.
+    - It is not a capability negotiation mechanism: clients do not advertise

Review Comment:
   Made it precise: clients MUST NOT use the header to advertise features, and servers MUST NOT infer from it which features a client supports. It also points to the `endpoints` field of the config response, which is where feature support is advertised.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4356375147


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2200,70 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:

Review Comment:
   Good catch. I moved the format rules into the Client Identification section of the API description, which does render, and removed the unreferenced parameter.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r3937166829


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Recommended header for a client to identify itself to the catalog. It
+        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+        5.5.3): a whitespace-separated list of `product/version` tokens,
+        optionally followed by a parenthesized comment.
+
+
+        Tokens SHOULD be ordered from the outermost component to the innermost,
+        so the most specific caller appears first: the engine or application,
+        then any integration or connector, then the Iceberg client library,
+        then the language runtime. The Iceberg client library token is the one
+        component every client can supply and SHOULD always be present.
+        Recommended library tokens are `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, and `iceberg-go`.
+
+
+        The trailing parenthesized comment is an open extension point for
+        additional, lower-value context such as build identifiers, the HTTP
+        library, or the operating system, given as bare tokens or `key=value`
+        pairs separated by `; `. Servers SHOULD treat the comment as free-form
+        and MUST NOT depend on its contents.
+
+
+        Examples:
+
+
+        `pyiceberg/0.11.0 (cpython/3.11.4)` — a client library used directly.
+
+
+        `Trino/438 iceberg-java/1.9.0 (jvm/17.0.9)` — an engine embedding the
+        Iceberg Java library.
+
+
+        `Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala/2.13.16)` —
+        an engine with a connector layer on top of the library.
+
+
+        This header is optional and informational; see "Client Identification"
+        in the API description for the rules that apply to all client-identity
+        headers. Servers MUST NOT reject a request based on its presence,

Review Comment:
   Fair point, agreed. Reworded so servers MAY refuse operations from client versions known to be broken/unsafe (e.g. corrupt stats). Kept the rule that they can't reject just because the header is missing or malformed, so clients that don't send it still work.
   



##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Recommended header for a client to identify itself to the catalog. It
+        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+        5.5.3): a whitespace-separated list of `product/version` tokens,
+        optionally followed by a parenthesized comment.
+
+
+        Tokens SHOULD be ordered from the outermost component to the innermost,
+        so the most specific caller appears first: the engine or application,
+        then any integration or connector, then the Iceberg client library,
+        then the language runtime. The Iceberg client library token is the one
+        component every client can supply and SHOULD always be present.
+        Recommended library tokens are `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, and `iceberg-go`.
+
+
+        The trailing parenthesized comment is an open extension point for
+        additional, lower-value context such as build identifiers, the HTTP
+        library, or the operating system, given as bare tokens or `key=value`
+        pairs separated by `; `. Servers SHOULD treat the comment as free-form
+        and MUST NOT depend on its contents.
+
+
+        Examples:
+
+
+        `pyiceberg/0.11.0 (cpython/3.11.4)` — a client library used directly.

Review Comment:
   Good catch — no, the parens are an RFC comment, not product tokens. The runtime bits belong there as free-form context. Clarified the wording and fixed the examples so the parenthesized part reads as a comment (e.g. `(jvm 17.0.9)`).
   



##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Recommended header for a client to identify itself to the catalog. It
+        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+        5.5.3): a whitespace-separated list of `product/version` tokens,
+        optionally followed by a parenthesized comment.
+
+
+        Tokens SHOULD be ordered from the outermost component to the innermost,
+        so the most specific caller appears first: the engine or application,
+        then any integration or connector, then the Iceberg client library,
+        then the language runtime. The Iceberg client library token is the one
+        component every client can supply and SHOULD always be present.
+        Recommended library tokens are `iceberg-java`, `pyiceberg`,

Review Comment:
   Done — the Iceberg library token is now MUST-be-present when the header is sent, and the format is normative rather than "recommended". I left token ordering as SHOULD since servers can match by known product name regardless of position, but happy to tighten it if you'd prefer.
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "singhpk234 (via GitHub)" <gi...@apache.org>.
singhpk234 commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-5365906700

   This is a nice addition, can you please open a dev DISCUSS thread as well !


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6072428031

   > @rahulsmahadev please rebase to fix CVE failures.
   
   Done


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "openinx (via GitHub)" <gi...@apache.org>.
openinx commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4190052903


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2196,64 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the
+        outermost component to the innermost, so the most specific caller
+        appears first: the engine or application, then any integration or
+        connector, then the Iceberg library.
+
+
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. These

Review Comment:
   we'd also clearly define what's the format will be looks like if someone add more than two platform/runtime versions in a single user-agent 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "adutra (via GitHub)" <gi...@apache.org>.
adutra commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r3916426196


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Recommended header for a client to identify itself to the catalog. It
+        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+        5.5.3): a whitespace-separated list of `product/version` tokens,
+        optionally followed by a parenthesized comment.
+
+
+        Tokens SHOULD be ordered from the outermost component to the innermost,
+        so the most specific caller appears first: the engine or application,
+        then any integration or connector, then the Iceberg client library,
+        then the language runtime. The Iceberg client library token is the one
+        component every client can supply and SHOULD always be present.
+        Recommended library tokens are `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, and `iceberg-go`.
+
+
+        The trailing parenthesized comment is an open extension point for
+        additional, lower-value context such as build identifiers, the HTTP
+        library, or the operating system, given as bare tokens or `key=value`
+        pairs separated by `; `. Servers SHOULD treat the comment as free-form
+        and MUST NOT depend on its contents.
+
+
+        Examples:
+
+
+        `pyiceberg/0.11.0 (cpython/3.11.4)` — a client library used directly.

Review Comment:
   Out of curiosity, does the RFC accept product identifiers surrounded by parentheses?



##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2181,56 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Recommended header for a client to identify itself to the catalog. It
+        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
+        5.5.3): a whitespace-separated list of `product/version` tokens,
+        optionally followed by a parenthesized comment.
+
+
+        Tokens SHOULD be ordered from the outermost component to the innermost,
+        so the most specific caller appears first: the engine or application,
+        then any integration or connector, then the Iceberg client library,
+        then the language runtime. The Iceberg client library token is the one
+        component every client can supply and SHOULD always be present.
+        Recommended library tokens are `iceberg-java`, `pyiceberg`,

Review Comment:
   In order to make this new header format actionable by servers, I'd suggest making at least the library product mandatory (i.e., "MUST be present"), and the tokens should be prescriptive, not "recommended".



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6156617720

   @singhpk234 and @openinx can I get a review


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "danielcweeks (via GitHub)" <gi...@apache.org>.
danielcweeks commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4097779386


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg

Review Comment:
   I don't think this was intended to be an exhaustive list. There are proprietary/custom implementations that should also identify themselves.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4140164381


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg
+        library uses its own product token in that position. The remaining
+        tokens SHOULD be ordered from the outermost component to the innermost,
         so the most specific caller appears first: the engine or application,
-        then any integration or connector, then the Iceberg client library,
-        then the language runtime. The Iceberg client library token is the one
-        component every client can supply and SHOULD always be present.
-        Recommended library tokens are `iceberg-java`, `pyiceberg`,
-        `iceberg-rust`, and `iceberg-go`.
+        then any integration or connector, then the Iceberg library, then the
+        language runtime.

Review Comment:
   Done



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "openinx (via GitHub)" <gi...@apache.org>.
openinx commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4190043654


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2196,64 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the
+        outermost component to the innermost, so the most specific caller
+        appears first: the engine or application, then any integration or
+        connector, then the Iceberg library.
+
+
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. These

Review Comment:
   could you pls give one example in the below to show the user-agent with runtime + os specificed at the same time ? 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4140156916


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2162,6 +2186,64 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the
+        outermost component to the innermost, so the most specific caller
+        appears first: the engine or application, then any integration or
+        connector, then the Iceberg library.
+
+
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. These
+        context items SHOULD be grouped into a single comment placed after all
+        product tokens rather than interleaved between them, and separated by
+        `; ` when there is more than one, for example `(jvm 17.0.9; ubuntu
+        26.04)`. Everything inside the parentheses is a free-form comment
+        rather than a `product/version` token; servers SHOULD treat it as
+        opaque and MUST NOT depend on its contents.
+
+
+        Examples:
+
+
+        `pyiceberg/0.11.0 (cpython 3.11.4)` — a client library used directly.
+
+
+        `Trino/438 iceberg-java/1.9.0 (jvm 17.0.9)` — an engine embedding the
+        Iceberg Java library.
+
+
+        `Spark/4.0.0 iceberg-spark/1.9.0 iceberg-java/1.9.0 (scala 2.13.16)` —
+        an engine with a connector layer on top of the library.
+
+
+        The header is advisory: a server MUST NOT reject a request only because
+        it is absent, incomplete, or malformed. See "Client Identification" in
+        the API description for the full rules that apply to client-identity
+        headers.

Review Comment:
   makes sense, changed to SHOULD NOT



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "adutra (via GitHub)" <gi...@apache.org>.
adutra commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-5954348861

   Thanks @rahulsmahadev LGTM!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4290683598


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,37 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable
+    format gives catalog operators usable telemetry for observability,
+    debugging, and support across the many engines and libraries that speak
+    this protocol. The recommended format is defined by the `User-Agent`
+    parameter in the components section of this document.
+
+    Client identification is advisory:
+
+    - Servers SHOULD NOT reject a request only because the header is absent,
+      incomplete, or malformed. Clients that do not send it remain fully
+      functional.
+    - The value is client-asserted and can be spoofed, so servers MUST NOT use
+      it for authentication or authorization.
+    - It is not a capability negotiation mechanism: clients do not advertise
+      the protocol features they support through this header, and servers do
+      not use it to select features or vary response content.
+    - Servers MAY refuse specific operations when the header identifies a

Review Comment:
   How can I a server refuse? Any recommended status code or error?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "openinx (via GitHub)" <gi...@apache.org>.
openinx commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6476768692

   Approved,  but I will wait @manuzhang @singhpk234  for the approval before I merge it.  thanks @rahulsmahadev  for the work. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-5503171976

   @singhpk234 thanks! Opened a DISCUSS thread on the dev list: https://lists.apache.org/thread/d6hkx66o8qc1lolh11l1lmswxlq0bpj9


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4290679427


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,37 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable
+    format gives catalog operators usable telemetry for observability,
+    debugging, and support across the many engines and libraries that speak
+    this protocol. The recommended format is defined by the `User-Agent`
+    parameter in the components section of this document.
+
+    Client identification is advisory:
+
+    - Servers SHOULD NOT reject a request only because the header is absent,
+      incomplete, or malformed. Clients that do not send it remain fully
+      functional.
+    - The value is client-asserted and can be spoofed, so servers MUST NOT use
+      it for authentication or authorization.
+    - It is not a capability negotiation mechanism: clients do not advertise

Review Comment:
   "do not"s used in this sentence are quite vaque.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4356386673


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,37 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable
+    format gives catalog operators usable telemetry for observability,
+    debugging, and support across the many engines and libraries that speak
+    this protocol. The recommended format is defined by the `User-Agent`
+    parameter in the components section of this document.
+
+    Client identification is advisory:
+
+    - Servers SHOULD NOT reject a request only because the header is absent,
+      incomplete, or malformed. Clients that do not send it remain fully
+      functional.
+    - The value is client-asserted and can be spoofed, so servers MUST NOT use
+      it for authentication or authorization.
+    - It is not a capability negotiation mechanism: clients do not advertise
+      the protocol features they support through this header, and servers do
+      not use it to select features or vary response content.
+    - Servers MAY refuse specific operations when the header identifies a

Review Comment:
   Added a recommendation: return the standard error response with status 400 and a message that names the refused version.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4356378516


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2200,70 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the

Review Comment:
   Reworded: all product tokens are ordered from the outermost component to the innermost, ending with the Iceberg library.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4356381251


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2200,70 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the

Review Comment:
   Tokens go from the outermost component to the innermost, so the library token is the last product token. The section now says that explicitly, so a server can find the library by position whatever tokens come before it.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4140159337


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg
+        library uses its own product token in that position. The remaining
+        tokens SHOULD be ordered from the outermost component to the innermost,
         so the most specific caller appears first: the engine or application,
-        then any integration or connector, then the Iceberg client library,
-        then the language runtime. The Iceberg client library token is the one
-        component every client can supply and SHOULD always be present.
-        Recommended library tokens are `iceberg-java`, `pyiceberg`,
-        `iceberg-rust`, and `iceberg-go`.
+        then any integration or connector, then the Iceberg library, then the
+        language runtime.
 
 
-        The trailing parenthesized comment is an open extension point for
-        additional, lower-value context such as build identifiers, the HTTP
-        library, or the operating system, given as bare tokens or `key=value`
-        pairs separated by `; `. Servers SHOULD treat the comment as free-form
-        and MUST NOT depend on its contents.
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. Everything

Review Comment:
   clarified



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "rahulsmahadev (via GitHub)" <gi...@apache.org>.
rahulsmahadev commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4140161534


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg

Review Comment:
   added clarifiication that the list is illustrative and not exhaustive



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "adutra (via GitHub)" <gi...@apache.org>.
adutra commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4095317576


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg
+        library uses its own product token in that position. The remaining
+        tokens SHOULD be ordered from the outermost component to the innermost,
         so the most specific caller appears first: the engine or application,
-        then any integration or connector, then the Iceberg client library,
-        then the language runtime. The Iceberg client library token is the one
-        component every client can supply and SHOULD always be present.
-        Recommended library tokens are `iceberg-java`, `pyiceberg`,
-        `iceberg-rust`, and `iceberg-go`.
+        then any integration or connector, then the Iceberg library, then the
+        language runtime.

Review Comment:
   Language runtime is mentioned twice: here as a product token, then below (line 2212) as a comment. I think the final intent is to move language runtime info to comments.



##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg
+        library uses its own product token in that position. The remaining
+        tokens SHOULD be ordered from the outermost component to the innermost,
         so the most specific caller appears first: the engine or application,
-        then any integration or connector, then the Iceberg client library,
-        then the language runtime. The Iceberg client library token is the one
-        component every client can supply and SHOULD always be present.
-        Recommended library tokens are `iceberg-java`, `pyiceberg`,
-        `iceberg-rust`, and `iceberg-go`.
+        then any integration or connector, then the Iceberg library, then the
+        language runtime.
 
 
-        The trailing parenthesized comment is an open extension point for
-        additional, lower-value context such as build identifiers, the HTTP
-        library, or the operating system, given as bare tokens or `key=value`
-        pairs separated by `; `. Servers SHOULD treat the comment as free-form
-        and MUST NOT depend on its contents.
+        The optional trailing comment, enclosed in parentheses as defined by
+        the RFC, carries lower-value context such as build identifiers, the
+        HTTP library, the language runtime, or the operating system. Everything

Review Comment:
   It would be good to clarify:
   
   1. whether all of these items should appear in different comments, or together in a single one, or both? E.g.
     ```
     (apache-http 5.0; jvm 17.0.9; ubuntu 26.04)
     (apache-http 5.0) (jvm 17.0.9) (ubuntu 26.04)
     ```
   2. whether comments can appear interleaved with products, or only at the end after the products.
   
   The RFC allows all of the above, but maybe we could restrict the expected format to facilitate parsing.



##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2185,51 +2190,54 @@ components:
       name: User-Agent
       in: header
       description: >
-        Recommended header for a client to identify itself to the catalog. It
-        follows the standard HTTP `User-Agent` grammar (RFC 7231, Section
-        5.5.3): a whitespace-separated list of `product/version` tokens,
-        optionally followed by a parenthesized comment.
-
-
-        Tokens SHOULD be ordered from the outermost component to the innermost,
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, or `iceberg-go`. A client not built on an Iceberg

Review Comment:
   How about `iceberg-cpp`?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "openinx (via GitHub)" <gi...@apache.org>.
openinx commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4190015779


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -25,9 +25,33 @@ info:
     name: Apache 2.0
     url: https://www.apache.org/licenses/LICENSE-2.0.html
   version: 0.0.1
-  description:
+  description: |
     Defines the specification for the first version of the REST Catalog API.
     Implementations should ideally support all Iceberg table spec versions.
+
+    ## Client Identification
+
+    Clients SHOULD identify themselves to the catalog using the standard HTTP
+    `User-Agent` header (RFC 7231, Section 5.5.3). A consistent, parseable
+    format gives catalog operators usable telemetry for observability,
+    debugging, and support across the many engines and libraries that speak
+    this protocol. The recommended format is defined by the `User-Agent`
+    parameter in the components section of this document.
+
+    Client identification is advisory:
+
+    - Servers SHOULD NOT reject a request only because the header is absent,
+      incomplete, or malformed. Clients that do not send it remain fully
+      functional.
+    - The value is client-asserted and can be spoofed, so servers MUST NOT use
+      it for authentication or authorization.
+    - It is not a capability negotiation mechanism: clients do not advertise
+      the protocol features they support through this header, and servers do
+      not use it to select features or vary response content.
+    - Servers MAY refuse specific operations for client versions known to be

Review Comment:
   Is this contradictory with the 1st sentence `Servers SHOULD NOT reject a request` ?  because the client's user-agent is a best-effort and not fully trustable,  it will be easier to give the false positive rejections. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#issuecomment-6041767630

   @rahulsmahadev please rebase to fix CVE failures.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4290633106


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2200,70 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:

Review Comment:
   This is not referenced by any operation and will be ignored by renderer.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org


Re: [PR] OpenAPI: Recommend a standard User-Agent format for REST clients [iceberg]

Posted by "manuzhang (via GitHub)" <gi...@apache.org>.
manuzhang commented on code in PR #17727:
URL: https://github.com/apache/iceberg/pull/17727#discussion_r4290651676


##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2172,6 +2200,70 @@ components:
       explode: false
       example: "vended-credentials,remote-signing"
 
+    user-agent:
+      name: User-Agent
+      in: header
+      description: >
+        Header for a client to identify itself to the catalog. It follows the
+        standard HTTP `User-Agent` grammar (RFC 7231, Section 5.5.3): a
+        whitespace-separated list of `product/version` tokens, optionally
+        followed by a parenthesized comment.
+
+
+        Clients SHOULD send this header. When it is sent, the Iceberg client
+        library token MUST be present so that a server can always identify the
+        library and its version: use the token for the Iceberg library the
+        client is built on, such as `iceberg-java`, `pyiceberg`,
+        `iceberg-rust`, `iceberg-go`, or `iceberg-cpp`. This list is
+        illustrative, not exhaustive: any other Iceberg library, or a
+        proprietary or custom implementation, uses its own descriptive product
+        token in that position. The remaining tokens SHOULD be ordered from the

Review Comment:
   what do you mean by "The remaining tokens"?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org