danielcweeks commented on code in PR #18080:
URL: https://github.com/apache/iceberg/pull/18080#discussion_r4023245265
##########
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:
I don't agree with this. If both modes are provided, it means that the
client will support and use either one. The header was intended to allow for
multiple modes, so that should be supported.
--
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]
