We are using the GetEmail function to retrieve an HTML email from a url that contains embedded image urls. We have noticed that when any of the embedded image urls return an image in jpeg/exif format instead of jpeg/jfif format (i.e., there is an exif header block and not a jfif header block), the returned image is "converted" into html instead of being interpreted as an image. The resulting email contains a broken image for the url.
The embedded image url returns a Content-type of image/jpeg, but the Chilkat software seems to be ignoring this and attempting to decode the file type by reading the data. It appears that once it sees a null character after the "Exif header", it stops processing.
Any help in figuring out how to fix this issue would be greatly appreciated.
I can provide a new build for testing, but I would need to know the what build to provide. (When posting questions, please mention programming language, operating system, .NET Framework, 32-bit/64-bit or both, architecture, Visual Studio version, Perl version, Python version, or anything else that is necessary to identify what might be needed to provide a new build..)
Sorry about the missing information. We are using both 32 bit and 64 bit, C++ interface using Visual Studio 2008 on Windows Server 2008 R2.
Thanks Steve! I just turned my attention to this, but I'm having trouble getting the information I need to make the fix (which should be simple, I think). The MHT software looks at the 1st few bytes of a referenced file to see what it actually contains -- because the other information can be misleading or incorrect (usually it's not). Do you have a sample image file you can provide so I can open it in a hex editor to understand the format? If so, you may send it to firstname.lastname@example.org
I've sent a test image to email@example.com.
This new build should resolve the problem:
Thanks for the quick turnaround on the patch. The changes you made do appear to have fixed the problem.