You're going to need to attach a stack trace here. Based on a quick search leading to StackOverflow and a PHP test case the issue is something is shoving a line break in a header declaration and that isn't allowed.

Call stack
#       Function                                Location
1       JApplicationCms->execute()              path-to-staging\administrator\index.php:51
2       JApplicationAdministrator->doExecute()      path-to-staging\libraries\cms\application\cms.php:257
3       JApplicationAdministrator->dispatch()       path-to-staging\libraries\cms\application\administrator.php:152
4       JComponentHelper::renderComponent()     path-to-staging\libraries\cms\application\administrator.php:98
5       JComponentHelper::executeComponent()        path-to-staging\libraries\cms\component\helper.php:380
6       require_once()                              path-to-staging\libraries\cms\component\helper.php:405
7       JControllerLegacy->execute()                path-to-staging\administrator\components\com_content\content.php:21
8       ContentController->display()                path-to-staging\libraries\legacy\controller\legacy.php:728
9       JControllerLegacy->display()                path-to-staging\administrator\components\com_content\controller.php:52
10      ContentViewArticles->display()              path-to-staging\libraries\legacy\controller\legacy.php:690
11      JViewLegacy->get()                      path-to-staging\administrator\components\com_content\views\articles\view.html.php:42
12      ContentModelArticles->getAuthors()      path-to-staging\libraries\legacy\view\legacy.php:401
13      JDatabaseDriver->loadObjectList()       path-to-staging\administrator\components\com_content\models\articles.php:361
14      JDatabaseDriverMysqli->execute()        path-to-staging\libraries\joomla\database\driver.php:1689

That's not all that helpful in this case. The stack trace for the call to the application's setHeader() method that errors out is what's needed. In JApplicationWeb::setHeader() add this snippet:

var_dump(debug_backtrace(), func_get_args());

gist here https://gist.github.com/wojsmol/5de46d26ba90e7aff933d74305b3c5bf

The relevant piece is here:

["args"]=> array(2) { [0]=> &string(6) "status" [1]=> &string(204) "500 Table 'staging20062016.#__content' doesn't exist SQL=SELECT u.id AS value, u.name AS text FROM #__users AS u INNER JOIN #__content AS c ON c.created_by = u.id GROUP BY u.id, u.name ORDER BY u.name" } }

It may look harmless, but in fact it's not. JDocumentError::render() sets the HTTP response header to the appropriate status code and uses the Exception object's message as the status text and attempts to cope with line returns by stripping the \n character.

Backing up a little further now, when a JDatabaseQuery object is converted to a string, the individual JDatabaseQueryElement objects go through JDatabaseQueryElement::__toString() which adds a PHP_EOL character to the front of each converted element.

In PHP 5.3.10 PHP_EOL can be defined in one of three ways; luckily as of PHP 5.4.1 it's down to two.

All this to say there are a few issues to look at here. First, why are we setting a status header with a custom message versus using a more standardized message which we do with 30x responses. Second one is why are we trying to "pretty print" SQL queries with arbitrary formatting; a space character is just as efficient as PHP_EOL for splitting things up. Third, why is the string replacement in JDocumentError::render() only accounting for \n line break characters and not factoring in \r as well.

With the removal of queries from Exception messages, this is in better shape. #13184 should fix this completely.