singhpk234 commented on code in PR #18080:
URL: https://github.com/apache/iceberg/pull/18080#discussion_r4499135983
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1410,34 @@ paths:
- $ref: '#/components/parameters/prefix'
- $ref: '#/components/parameters/namespace'
- $ref: '#/components/parameters/table'
+ - $ref: '#/components/parameters/data-access'
post:
tags:
- Catalog API
summary: Remotely signs requests to object storage
operationId: signRequest
+ description: >
+ Signs a request to object storage on the client's behalf.
+
+
+ `RemoteSignResult` reports the mechanism that produced the signature in
+ `signing-mechanism`. With `remote-signing`, `headers` carries the
signature. With
+ `remote-presigning`, `uri` carries the signature.
+
+
+ On this operation `X-Iceberg-Access-Delegation` lists the access
delegation mechanisms
+ the client supports for this request: `remote-signing`,
`remote-presigning`, or both.
+ Other values, such as `vended-credentials`, are not supported on this
operation and do
+ not count as listed mechanisms. The server SHOULD answer with one of
the listed
+ mechanisms, and chooses when both are listed. The server SHOULD
respond with 406, rather
+ than answer with another mechanism, when the header lists no mechanism
the server
+ implements. For example, `vended-credentials` lists no mechanism, and
+ `vended-credentials,remote-signing` lists only `remote-signing`.
Review Comment:
what if its 'vended-creds,remote-presigning' and the server doesn't support
remote-presigning we expect server to give 406 right ?
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -5847,6 +5872,11 @@ components:
description: The storage provider for which the request is to be
signed. The provider should correspond to
the scheme used for a storage native URI. For example `s3` for AWS
S3 paths. For backwards compatibility,
if this is not specified, the provider is assumed to be `s3`.
+ plan-id:
+ type: string
+ description: >
+ Optional identifier of the server side scan plan, supplied for
audit and correlation. A server
+ MUST NOT fail a request because the referenced plan is unknown,
expired, or cancelled.
Review Comment:
Q: why can't server fail if the plan is cancelled if the plan is cancelled
with a bad request ? i would rather just remove the statement of when to fail ?
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -5847,6 +5872,11 @@ components:
description: The storage provider for which the request is to be
signed. The provider should correspond to
the scheme used for a storage native URI. For example `s3` for AWS
S3 paths. For backwards compatibility,
if this is not specified, the provider is assumed to be `s3`.
+ plan-id:
+ type: string
+ description: >
+ Optional identifier of the server side scan plan, supplied for
audit and correlation. A server
+ MUST NOT fail a request because the referenced plan is unknown,
expired, or cancelled.
Review Comment:
why can't server fail if the plan is cancelled if the plan is cancelled with
a bad request ? i would rather just remove the statement of when to fail ?
--
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]
