adutra commented on PR #17627: URL: https://github.com/apache/iceberg/pull/17627#issuecomment-5316564280
Hi @dramaticlly thanks for tackling this! Unfortunately things have changed since #15451 : When I last modified `S3V4RestSignerClient` in #15451, the consensus back then was that the signer endpoint could be dynamically generated by the server. One of the reasons for this idea was that servers could wish to encode authorization data in the signer endpoint URL. Therefore, we agreed back then that the endpoint path _must_ be provided by the server, as there is no good default. However in #16822, things changed in the opposite direction. Following [this feedback](https://github.com/apache/iceberg/pull/16822#pullrequestreview-4604404874), we decided instead that the signer endpoint would be "just" a regular endpoint, and its URL could be deterministically inferred as follows: ``` <catalog base uri>/v1/{prefix}/namespaces/{namespace}/tables/{table}/sign ``` (The same PR decided that server-specific data would from now on be communicated separately to signer clients via the new `RemoteSigningConfig` object.) As a consequence, `signer.endpoint` and `signer.uri` were themselves deprecated in the spec, as now the client is capable of inferring the endpoint from the catalog URI + prefix + table identifier. That's why I think this PR should not require `signer.endpoint` to be set. I'm OK with removing the deprecated classes and deprecated fields, but I'd prefer that you leave the `signer.endpoint` changes out of it. I am planning to provide a PR very shortly to introduce support for `RemoteSigningConfig` in the Java code, and that will also take care of `signer.endpoint`. Would that work for you? Thanks! -- 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]
