Semantics of constrained blob streams for the server

[david-perez]

What should a server do upon receiving a streaming blob that does not satisfy the modeled constraint traits?

Currently, the only allowed constraint trait on the blob shape is the length trait.

When the blob is non-streaming, the server framework can buffer the entire request body in memory, check the length, and only then hand the blob to the application code. This is what smithy-rs does in this case.

However, when the blob is streaming, the intention is that the application code can begin working with the stream of bytes as they come in, processing the stream chunk by chunk. For example, smithy-rs hands the application code a aws_smithy_http::byte_stream::ByteStream, a type that implements the Stream trait, that users can lazily poll for chunks of Bytes.

So, how should a server enforce a length constraint trait on the streaming blob?

1. Should it keep track of how many bytes the application code has polled, and error out the moment it attempts to poll past the length.max value?
2. How do we enforce length.min?

Bear in mind that application code is free to poll the stream however much they need. That is, it's perfectly valid for application code to poll n bytes (and possibly start rendering a response!) and ignore (or not) the rest. Perhaps n is not within the modeled length bounds, but the full blob stream the client sent is.