Add the remaining contract tests for the RC token gate: a 16-hex-char
token with no colon stays on the malformed-token 400 path, and the
legacy descriptor header takes precedence when an RC-shaped combined
token is also present. Note in the malformed non-hex case that the 400
expectation is for the standalone test app; the production fiber error
handler currently maps it to 500, which is pre-existing behavior.
Signed-off-by: Jihyeon Gim <potatogim@potatogim.net>
The RDMA token parser accepts only the cuObject combined-token format,
whose first colon-delimited field is a hex-encoded uint64 base address
(at most 16 hex chars). Fixed-width binary RC token schemes such as AMD
hipObject's (a 44-byte payload hex-encoded to 88 chars, optionally
suffixed with ":addr:size") fail that parse and produce a 400 Bad
Request. hipObject clients treat a 400 as a hard failure: they fall
back to the HTTP data path only when the response carries no
x-amz-rdma-reply header, so the 400 blocks the fallback entirely.
Reject structurally incompatible token schemes with 501 Not
Implemented instead. The first field being longer than 16 hex chars
(and entirely hex) cannot be a valid cuObject base address, so this
never reclassifies well-formed cuObject tokens; non-hex fields still
fall through to the existing malformed-token 400 path. The 501 response
is serialized and sent directly from the middleware because the global
error handler collapses non-fiber errors into 500, and the
x-amz-rdma-reply header is deliberately left unset so RDMA-capable
clients recognize the gateway as RDMA-unsupported for this request and
use the HTTP path.
Signed-off-by: Jihyeon Gim <potatogim@potatogim.net>
Jihyeon Gim
Ben McClelland