sungwy commented on code in PR #16394:
URL: https://github.com/apache/iceberg/pull/16394#discussion_r3266735298
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -311,6 +313,7 @@ paths:
summary: Create a namespace
parameters:
- $ref: '#/components/parameters/idempotency-key'
+ - $ref: '#/components/parameters/client-capabilities'
Review Comment:
Is there a reason why we are adding client capabilities header to
`/v1/{prefix}/namespaces`?
`read-restrictions`, `vended-credentials` and `remote-signing` are not
capabilities related to namespace maintenance requests. Would it make more
sense to leave it out until capability negotiation is needed for namespaces?
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -2019,6 +2058,50 @@ components:
explode: false
example: "vended-credentials,remote-signing"
+ client-capabilities:
+ name: X-Iceberg-Client-Capabilities
+ in: header
+ description: >
+ This header is a forward-compatibility hint, not a security mechanism.
+ Clients can trivially spoof its value; servers MUST NOT base trust or
+ authorization decisions on it.
+
+
+ Optional signal from the client declaring the set of capabilities that
+ the client SDK supports, as a comma-separated list. This header is
+ sent on every request. The server may use this information to tailor
+ its responses.
+
+
+ Defined capability values:
+
+ - `vended-credentials`: The client supports receiving and using
+ storage credentials vended by the catalog server.
+
+ - `remote-signing`: The client supports delegating request signing
+ to a remote signing service provided by the catalog server.
+
+ - `scan-planning`: The client supports server-side scan planning.
Review Comment:
I wonder if these capability values should include a major compatibility
version, since values like `read-restrictions` may evolve in ways that older
clients cannot safely consume. Would `read-restrictions.v1` make more sense, so
that incompatible future semantics can be represented as `read-restrictions.v2`?
This would allow us to introduce a new column mask subtype in
read-restrictions without worrying about breaking the existing capability
header contract, by simply introducing a new capability 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: [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]
