JAMES-4172 Fix truncated downloads for non-SingleBody EmailBodyPart b…#2940
JAMES-4172 Fix truncated downloads for non-SingleBody EmailBodyPart b…#2940omerfarukicen wants to merge 4 commits intoapache:masterfrom
Conversation
…lobs In EmailBodyPartBlob, the size and content methods used different calculation paths for non-SingleBody parts (e.g. message/rfc822): - size relied on SizeUtils.sizeOf(entity) which returns the decoded size via SingleBody.size() - content used DefaultMessageWriter.writeBody() which re-encodes the content (e.g. base64), producing more bytes than the decoded size This mismatch caused Content-Length to be set smaller than the actual response body, resulting in truncated .eml downloads with missing attachments and MIME boundaries. Fix by caching the written body bytes in a lazy val so that both size and content use the same data, ensuring Content-Length matches the actual stream length.
|
The test This is expected: the old code used Since Shall I update the test to expect |
Likely yes! |
|
Can you check pipeline process? |
|
Hello |
|
JSON documents are different: "size":807 is expected... expected: <{"attachments":[{"blobId":"1_3_3","charset":"UTF-8","disposition":"attachment","name":"whatever.txt","partId":"3","size":16,"type":"text/plain"}],"blobId":"1_3","bodyValues":{"2":{"isEncodingProblem":false,"isTruncated":false,"value":"test body |
https://issues.apache.org/jira/browse/JAMES-4172
In EmailBodyPartBlob, the size and content methods used different calculation paths for non-SingleBody parts (e.g. message/rfc822):
This mismatch caused Content-Length to be set smaller than the actual response body, resulting in truncated .eml downloads with missing attachments and MIME boundaries.
Fix by caching the written body bytes in a lazy val so that both size and content use the same data, ensuring Content-Length matches the actual stream length.