Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attachment problem: read 2 bytes more data than requested #106

Closed
beldeveloper opened this issue Jan 27, 2020 · 3 comments
Closed

Attachment problem: read 2 bytes more data than requested #106

beldeveloper opened this issue Jan 27, 2020 · 3 comments
Labels
bug

Comments

@beldeveloper
Copy link

@beldeveloper beldeveloper commented Jan 27, 2020

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

This comment has been minimized.

Copy link
Owner

@zbateson zbateson commented Feb 5, 2020

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 zbateson added the bug label Feb 5, 2020
@zbateson

This comment has been minimized.

Copy link
Owner

@zbateson zbateson commented Feb 10, 2020

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.

@zbateson zbateson closed this Feb 10, 2020
@beldeveloper

This comment has been minimized.

Copy link
Author

@beldeveloper beldeveloper commented Feb 17, 2020

Hello @zbateson
Really appreciate your quick help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.