Forums » Upgrade to 1.4: 500 Errors on "browse" pages

RSS feed for this topic

Info

  1. ebellempire Posted 11 months ago

    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?

  2. John Flatness (Omeka Dev Team) Posted 11 months ago

    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.

  3. ebellempire Posted 11 months ago

    Here's the error detail:

    [Sun Jun 26 11:11:09 2011] [error] [client 107.10.33.69] 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.

  4. John Flatness (Omeka Dev Team) Posted 11 months ago

    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.

  5. ebellempire Posted 11 months ago

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

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

  6. John Flatness (Omeka Dev Team) Posted 11 months ago

    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.

  7. ebellempire Posted 11 months ago

    Yep, that did it!

    Thanks, John.

  8. John Flatness (Omeka Dev Team) Posted 11 months ago

    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.

Reply

You must log in to post.