Skip to content

[Incremental Delivery RFC] Requirement on Content-Length #136

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ificator opened this issue Sep 4, 2020 · 1 comment
Closed

[Incremental Delivery RFC] Requirement on Content-Length #136

ificator opened this issue Sep 4, 2020 · 1 comment

Comments

@ificator
Copy link

ificator commented Sep 4, 2020

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.

@ificator
Copy link
Author

I just checked in on this, and it looks like #152 updated the RFC to remove my concern. Closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant