Warnings from EXIF reader cause malformed XMLRPC responses

[redsweater]

Note: This is a new bug in 2.5. The problem does not exist in 2.3.3.

The addition of the exif_read_data function in wp-admin/includes/image.php causes a scenario where the exif reader prints warning text directly to the output, thus corrupting both HTML and XMLRPC output in differing ways.

When the debug info is printed in the web/HTML based upload flow, it mainly just upsets the visual beauty of the web page, but when it is printed as part of the XMLRPC based upload flow, the text is inserted before the XML cargo and therefore violates the expectations of the protocol.

The problem at its core seems to be that exif_read_data will print warning information even for image types that are otherwise supported. Case #5397 ran into a similar version of this issue, but only partly fixed it by blocking out image types that are known to "provoke" the EXIF reader. I think there has to be some more radical fix for this, possibly by silencing the exif reader's warnings, or by redirecting those warnings temporarily to a non-stdout location?

The end result for users today of XMLRPC based clients is if they upload an image to 2.5 that triggers these warnings, the resulting XML is corrupted and the client is likely to reject the response as not well formed XML.

An example of an image that provokes such as a warning is attached. Note that images generated by Adobe products such as Lightroom or Photoshop seem to provoke the warnings.

An example of such a corrupted response is pasted here:

Response text:
<br />
<b>Warning</b>:  exif_read_data(waffles1.jpg) [<a href='function.exif-read-data'>function.exif-read-data</a>]: Incorrect APP1 Exif Identifier Code in <b>/Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-admin/includes/image.php</b> on line <b>238</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-admin/includes/image.php:238) in <b>/Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-includes/class-IXR.php</b> on line <b>363</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-admin/includes/image.php:238) in <b>/Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-includes/class-IXR.php</b> on line <b>364</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-admin/includes/image.php:238) in <b>/Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-includes/class-IXR.php</b> on line <b>365</b><br />
<br />
<b>Warning</b>:  Cannot modify header information - headers already sent by (output started at /Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-admin/includes/image.php:238) in <b>/Volumes/Data/Users/daniel/Documents/WebSites/red-sweater.com/wptrunk/wp-includes/class-IXR.php</b> on line <b>366</b><br />
<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
        <struct>
  <member><name>file</name><value><string>waffles.jpg</string></value></member>
  <member><name>url</name><value><string>http://192.168.1.20/wptrunk/wp-content/uploads/waffles1.jpg</string></value></member>
  <member><name>type</name><value><string>image/jpeg</string></value></member>
</struct>
      </value>
    </param>
  </params>
</methodResponse>

[redsweater]

An example image that will, when upload, cause exif_read_data to print debugging warnings.

[tellyworth]

Reproduced in test_exif_error():

​http://svn.automattic.com/wordpress-tests/wp-testcase/test_image.php

[tellyworth]

suppres the error

[tellyworth]

The patch suppresses the error. The unit test passes with the patch applied.

[redsweater]

This is a pretty awesome turnaround. Really impressed with the unit test response and fix - same day even!

Hope this can get in for 2.5.1 - will be a great turnaround for users who are dinged by this on 2.5.

Daniel

[redsweater]

FYI I confirmed that the supplied patch does indeed fix the problem as confirmed by trying to reproduce the image upload error with MarsEdit.

[tellyworth]

redsweater: thanks for the clear description and example image, that made it easy to reproduce and fix.

[ryan]

(In [7673]) Suppress exif_read_data() errors. Props tellyworth. fixes #6571 for trunk

[ryan]

(In [7674]) Suppress exif_read_data() errors. Props tellyworth. fixes #6571 for 2.5