Spec edits for multipart @defer @stream around content-length #152
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to amend a few things that were discovered upon implementation:
Content-Length
is not mentioned as a requirement from the multipart spec. The change will now reflect that the boundary is not the "start" of the part, but rather the end of the part. The first boundary being the end of the preamble. This will give clients a much more predictable "I have enough body" to then begin parsing. Rather than wait for the next boundary to flush, which as per sample implementations wouldn't flush till the next chunk was written, potentially delaying the processing of that part. This now means a client can consume chunks till a boundary, then parse.This will mean we're seeing a much tighter smaller payload, and easier to consume for clients.
cc @robrichard