Because OPEN-DECODED-FILE-PORTION only knows about transfer encodings it
would only return a character stream for 7bit encoded bodies. This
causes inconsistent behavior where some bodies would return binary and
some character streams. To fix this, we specialize MIME-BODY-STREAM for
MIME-TEXT parts which may or may not be a good enough solution.
We may actually want to make MIME-BODY-STREAM binary always and let the
user handle decoding?! This may be a good idea to take care after yet
another stream machinery redesign.
Since the mime4cl test suite doesn't test MIME-BODY-STREAM (much), add a
message generated by notemap that hits this issue to the mblog golden
test suite.
Change-Id: Ie340c42ced6c693af9b3c84b177408d6b6d2c9c4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12913
Reviewed-by: sterni <sternenseemann@systemli.org>
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
This should allow for refactors with more confidence as we can make sure
base functionality stays the same. It is important to test image
extraction, so unfortunately we need to check in a base64 rendering of
an image file. I've used //users/tvlbot.jpg, so git should at least be
able to deduplicate the extracted content. Note that this was achieved
by altering the note message since I wasn't able to add the picture in
the iOS Notes.app without the image being recompressed.
To get extra benefit, we also add the test note to the mime4cl test suite.
The expected output can be updated with
mblog $(mg build :maildir) expected
Change-Id: I0aa493b206439018ad89745bacbd47af78bd1396
Reviewed-on: https://cl.tvl.fyi/c/depot/+/12911
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: sterni <sternenseemann@systemli.org>
