sungwy commented on code in PR #18080:
URL: https://github.com/apache/iceberg/pull/18080#discussion_r4026983127
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1400,35 @@ 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. With `remote-signing`,
`uri` is the
+ requested URI and `headers` carries the signature. With
`presigned-urls`, `uri`
+ carries the signature and `headers` is empty.
Review Comment:
Thanks @danielcweeks - I had used an empty `headers` as the way to tell the
pre-signed forms apart, because I think it'll be useful for the client to
verify that the response is in the mode it wants for the specific use case.
I agree with you that we can simply require that the headers are sent in the
request to be more consistent with the protocol. And we could consider giving
up on the client being able to reliably distinguish which mode of signing it
had received from the REST server.
I'll add this as a future discussion point for the FILE access governance
discussions at the FILE sync.
##########
open-api/rest-catalog-open-api.yaml:
##########
@@ -1410,12 +1400,35 @@ 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. With `remote-signing`,
`uri` is the
+ requested URI and `headers` carries the signature. With
`presigned-urls`, `uri`
+ carries the signature and `headers` is empty.
+
+
+ `X-Iceberg-Access-Delegation` on this operation is not a capability
negotiation.
+ When used, the client selects the form of the result for this request,
and the
+ server SHOULD answer in that form. A server that does not implement
the requested
+ mode SHOULD respond with 406 rather than answer in another form.
+
+
+ Only `remote-signing` and `presigned-urls` are evaluated on this
operation. A request
+ that selects both modes is malformed, 400. When no mode is present the
request is
+ treated as `remote-signing`.
Review Comment:
Agree, I can see a client doing that. If a client doesn't want to ask for
both, it'll just send one mode in the header.
I agree it's simpler to keep this consistent with the original semantic of
X-Iceberg-Access-Delegation
--
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]
