Upgrade to 1.4: 500 Errors on "browse" pages

After upgrading, I'm getting 500 Errors on select browse pages, including collections (public and admin), items (public and admin), item-types, and all admin settings pages). Oddly all my other pages (public and admin) seem to work fine. I tried rewriting base in .htaccess but that did not change anything.

Actually, looking more closely, I see that this URL works: /collections/browse while this does not /collections - same pattern with items and on both admin and public sides. In fact, anywhere that you can add browse (themes, users, element-sets), it fixes the problem.

Any ideas?

Some things to try and help narrow this down:

  • First, check your server logs. A 500 error is often a symptom of a PHP error that should be logged, either in a dedicated log for PHP if you have it set up that way, or in your Apache logs.
  • Deactivate all your plugins, and try to find out if any particular plugin is causing this for you.

Here's the error detail:

[Sun Jun 26 11:11:09 2011] [error] [client] FastCGI: comm with server "/var/chroot/home/content/[my directory]/html-x-httpd-php5" aborted: error parsing headers: duplicate header 'Content-Type'

I believe I've eliminated the possibility that this issue is theme-/plugin-related.

Interesting. I've never seen this exact error before (though we generally don't run PHP through FastCGI around here).

Do you have some custom code somewhere that's setting the content-type? Omeka 1.4 uses the Zend Framework's header functions to set the Content-Type to text/html; charset=utf-8, but I'm unable to find any situations where the Content-Type gets sent twice.

Just did a fresh install on an empty DB and still getting the errors.

I'm on GoDaddy hosting. Maybe it is server-specific?

You can try this change to the line that sets the Content-Type header (line 79 of application/libraries/Omeka/Controller/Action.php):

The original is:

$response->setHeader('Content-Type', 'text/html; charset=utf-8');

And the change you can try is (adding a third true parameter):

$response->setHeader('Content-Type', 'text/html; charset=utf-8', true);

This doesn't seem to have any affect on a mod_php installation, but there could be some difference under mod_fcgi, which is what you appear to be using.

Yep, that did it!

Thanks, John.

Good to hear.

It seems like this is some combination between GoDaddy's use of FastCGI (which seems to hate multiple headers) and some sort of server setting for either PHP or Apache that's causing an extra Content-Type header.

That extra true parameter explicitly tells Zend to replace any previous values for the header when setting it. Adding that parameter won't negatively affect people for whom everything's working fine now, so this should be an easy quick fix.