Should we have some abstraction on the request class that provides a byte stream?
I understand this depends on the encoding and whatnot, and that currently the idea is that we read the bytes in the request and stash them away in the SigningMetadata if we need to validate the body signature. However, that results in us having to handle chunking in multiple places.
If we had some sort of "bytes provider" that read from the input stream (if any) and returned bytes when needed, we could centralize all this logic. The "bytes provider" could also return the same bytes it has read already if needed (such that we can validate signatures and then send those same bytes down the wire)
I understand this depends on the encoding and whatnot, and that currently the idea is that we read the bytes in the request and stash them away in the
SigningMetadataif we need to validate the body signature. However, that results in us having to handle chunking in multiple places.If we had some sort of "bytes provider" that read from the input stream (if any) and returned bytes when needed, we could centralize all this logic. The "bytes provider" could also return the same bytes it has read already if needed (such that we can validate signatures and then send those same bytes down the wire)
_Originally posted by @vagaerg in https://github.com/trinodb/s3-proxy/pull/48#discussion_r1640149613_