You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had a read through the proposal and it seems like Content-LengthMUST be provided for each part. I'm curious as to why this is the case - is it simply because it makes client implementation easier? From a service perspective accomplishing this behavior requires buffering the result of serialization in memory before being written to the response stream, which can have a negative impact on performance in high-throughput services. It's much more efficient to serialize directly to the response stream, and let the clients rely on the boundary markers to determine if a part is complete.
This would necessitate a more complex boundary marker, as proposed by #135.
The text was updated successfully, but these errors were encountered:
I had a read through the proposal and it seems like
Content-Length
MUST be provided for each part. I'm curious as to why this is the case - is it simply because it makes client implementation easier? From a service perspective accomplishing this behavior requires buffering the result of serialization in memory before being written to the response stream, which can have a negative impact on performance in high-throughput services. It's much more efficient to serialize directly to the response stream, and let the clients rely on the boundary markers to determine if a part is complete.This would necessitate a more complex boundary marker, as proposed by #135.
The text was updated successfully, but these errors were encountered: