Attachment problem: read 2 bytes more data than requested

[beldeveloper]

Hello!
There is an attachment in the email which can not be saved properly using the mail-mime-parser library. I try to do it the following way:
$handle = $att->getContentResourceHandle();
while (!feof($handle)) {
$part = fread($handle, 1024);
// ...
}

I use loop in order to control the size of the attachment and it works in the general cases. But fread() throws the following error on the special file:

fread(): GuzzleHttp\Psr7\StreamWrapper::stream_read - read 2 bytes more data than requested (8194 read, 8192 max) - excess data will be lost.

This issue can be reproduces using 1.1* and 1.2.0 versions. The example of the email, also the raw original attachment are in the zip file. Can you please look at this and advise something?
Thank you in advance!
example.zip

[zbateson]

Hi @beldeveloper,

Looking at this, I can reproduce the warning as well using fread, but writing the stream out still seems to be okay and the file doesn't look corrupted or anything. Can you confirm that?

I also noticed that using Psr7 streams doesn't produce a warning... changing your code like so:

$stream = $att->getContentStream();
while (!$stream->eof()) {
    $part = $stream->read(1024);
    // ...
}

But it may still indicate an underlying issue, and I'll have to dig deeper to see what's happening and what's causing it.

[zbateson]

Hi @beldeveloper,

It turns out the issue is related specifically to fread. Because the function returns 'bytes', and conversion to utf-8 in zbateson/stream-decoders returns chars, calling for example fread($handle, 1) will read 1 byte, and not 1 multibyte character for example.

For this reason I've deprecated usage of getContentResourceHandle, getTextResourceHandle and getHtmlResourceHandle. These should not be used to read character streams. Instead getContentStream, getTextStream and getHtmlStream should be used.

I've also found a bug reading UTF-16LE data while investigating this. I'm not entirely sure what the underlying problem was that was causing it, but aligning my byte reading to a 4-byte boundary seems to fix it. This didn't appear to be an issue for non-LE multibyte streams as far as I could tell... but as I don't really know the underlying issue there may be more to the bug. My testing is pretty comprehensive though and no longer causes an error, so I'm hopeful the alignment is all that was needed. This is released in zbateson/stream-decorators 1.0.3.

The actual deprecation in code will be a 1.2.1 release, but I might delay the actual release for some additional fixes as there's no specific change to code beyond marking the deprecated methods.

All the best.

[beldeveloper]

Hello @zbateson
Really appreciate your quick help!