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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
