singhpk234 commented on code in PR #15850:
URL: https://github.com/apache/iceberg/pull/15850#discussion_r3033111269
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -3522,6 +3522,11 @@ components:
If remote signing for a specific storage provider is enabled, clients
must respect the following configurations when creating a remote signer client:
- `signer.endpoint`: the remote signer endpoint. Required. Can either
be a relative path (to be resolved against `signer.uri`) or an absolute URI.
- `signer.uri`: the base URI to resolve `signer.endpoint` against.
Optional. Only meaningful if `signer.endpoint` is a relative path. Defaults to
the catalog's base URI if not set.
+ - `signer.properties.*`: additional properties to be passed through
to the signer endpoint in remote sign
+ requests. Optional. If such properties are present, signer clients
MUST pass them through to the signer
Review Comment:
1/ The way i see this is that its an optimization and not a requirement, so
spec should not mandate sending them back. Also it might be easy for current
iceberg java implementation, but what about other engines which don't use
iceberg java i would not make my assumptions.
I kind of disagree freshness of GRANTs is catalog concern, isn't the
credential (which are based on GRANTs) freshness a client concern ? is there
anything wrong if client comes back to catalog before the creds vended before
are expired ?
2/ I don't think we can reject those clients, we should ok with degrading
from catalog POV if this fields are not sent, the way to say this is that this
is entirely optimization not a requirement, if we go by this i think 1 would
make sense. for option to detect old client, first this is very tricky to
detect, except iceberg java no one send client version, second, i don't think
putting stuff to url is a good idea, it kind of defeats the standard body
construct i know there are sections in complete url where can stuff but i don't
recommend doing that.
--
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]
