Fix off-by-one error in get_blob with Range #766
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When range.end == decompressed.len(), the last value in the range will also be the last value in decompressed, because ranges ends are exclusive. This issue had two consequences that I have noticed. The first is that requesting the last (or only) message part via JMAP will result in the entire message being returned instead, because the range ends on the last byte of the message. The second issue, which resulted from the first, was that attempting to fetch the last (or only) message part would almost always fail when requested via JMAP if the message part used the quoted-printable transfer encoding. This is because Stalwart would attempt to decode the blob, but since the entire file was returned, this would include headers which are very likely to break assumptions made by the decoder, e.g. unexpected '=' tokens as in 'charset=UTF-8' The second issue was originally reported here: stalwartlabs#758
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When
range.end == decompressed.len(), the last value in the range will also be the last value indecompressed, because ranges ends are exclusive.This issue had two consequences that I have noticed. The first is that requesting the last (or only) message part via JMAP will result in the entire message being returned instead, because the range ends on the last byte of the message.
The second issue, which resulted from the first, was that attempting to fetch the last (or only) message part would almost always fail when requested via JMAP if the message part used the quoted-printable transfer encoding. This is because Stalwart would attempt to decode the blob, but since the entire file was returned, this would include headers which are very likely to break assumptions made by the decoder, e.g. unexpected '=' tokens as in 'charset=UTF-8'
The second issue was originally reported here:
#758