singhpk234 commented on code in PR #18080:
URL: https://github.com/apache/iceberg/pull/18080#discussion_r4201008113
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1400,31 @@ 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 one request to object storage on the client's behalf.
Review Comment:
```suggestion
Signs a request to object storage on the client's behalf.
```
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1400,31 @@ 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 one request to object storage on the client's behalf.
+
+
+ `RemoteSignResult` takes one of two forms, reported in
`signing-mechanism`. With
+ `remote-signing`, `headers` carries the signature. With
`remote-presigning`, `uri`
+ carries the signature.
+
+
+ `X-Iceberg-Access-Delegation` on this operation is not a capability
negotiation.
+ When used, the values are the forms the client can consume for this
request, and the
+ server SHOULD answer in one of them. A server that implements none of
the listed
+ modes SHOULD respond with 406 rather than answer in another form.
+
+
+ Only `remote-signing` and `remote-presigning` are evaluated on this
operation. A
+ request that lists both accepts either form and the server chooses.
When no mode is
+ present the request is treated as `remote-signing`.
Review Comment:
do we wanna add this is for the backward compatibility ?
what happens some one sends in this header vended-creds ? what should we do,
earlier this was not possible
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1400,31 @@ 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 one request to object storage on the client's behalf.
+
+
+ `RemoteSignResult` takes one of two forms, reported in
`signing-mechanism`. With
+ `remote-signing`, `headers` carries the signature. With
`remote-presigning`, `uri`
+ carries the signature.
Review Comment:
should we enforce that ? i wonder if we should just say here the we return
both headers and uri, i like what @danielcweeks suggested we can in our
reference impl pass in both header and the uri completely
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -5841,6 +5480,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 scan plan, supplied for audit and
correlation. A server
Review Comment:
```suggestion
Optional identifier of the server side scan plan, supplied for
audit and correlation. A server
```
wonder do we need to add more details on what this is for ?
for example in creds endpoint we dont do this, we can just call here, wdyt ?
https://github.com/apache/iceberg/blob/4a84ba420e51242ee6bb16c71b849d91e81d7d71/open-api/rest-catalog-open-api.yaml#L1379
--
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]
