Question

I get the following error within Magento CE 1.6.1.0

Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/dev/env/var/www/user/dev/wdcastaging/lib/Zend/Controller/Response/Abstract.php:586) in /home/dev/env/var/www/user/dev/wdcastaging/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 119

when accessing /api/soap/?wsdl

Apparently, a session_start() is being attempted after the entire contents of the WSDL file have already been output, resulting in the error.

Why is magento attempting to start a session after outputting all the datums? I’m glad you asked. So it looks like controller_front_send_response_after is being hooked by Mage_Persistent in order to call synchronizePersistentInfo(), which in turn ends up getting that session_start() to fire.

The interesting thing is that this wasn’t always happening, initially the WSDL loaded just fine for me, initially I racked my brains to try and see what customization may have been made to our install to cause this, but the tracing I’ve done seems to indicate that this is all happening entirely inside of core.

We have also experienced a tiny bit of (completely unrelated) strangeness with Mage_Persistent which makes me a little more willing to throw my hands up at this point and SO it.

I’ve done a bit of searching on SO and have found some questions related to the whole “headers already sent” thing in general, but not this specific case.

Any thoughts?

Oh, and the temporary workaround I have in place is simply disabling Mage_Persistent via the persistent/options/enable config data. I also did a little bit of digging as to whether it might be possible to observe an event in order to disable this module only for the WSDL controller (since that seems to be the only one having problems), but it looks like that module relies exclusively on this config flag to determine it’s enabled status.

UPDATE: Bug has been reported: http://www.magentocommerce.com/bug-tracking/issue?issue=13370

Answer 1

I’d report this is a bug to the Magento team. The Magento API controllers all route through standard Magento action controller objects, and all these objects inherit from the Mage_Api_Controller_Action class. This class has a preDispatch method

class Mage_Api_Controller_Action extends Mage_Core_Controller_Front_Action
{
    public function preDispatch()
    {
        $this->getLayout()->setArea('adminhtml');
        Mage::app()->setCurrentStore('admin');
        $this->setFlag('', self::FLAG_NO_START_SESSION, 1); // Do not start standart session
        parent::preDispatch();
        return $this;
    }
    //...
}

which includes setting a flag to ensure normal session handling doesn’t start for API methods.

$this->setFlag('', self::FLAG_NO_START_SESSION, 1);

So, it sounds like there’s code in synchronizePersistentInf that assumes the existence of a session object, and when it uses it the session is initialized, resulting in the error you’ve seen. Normally, this isn’t a problem as every other controller has initialized a session at this point, but the API controllers explicitly turns it off.

As far as fixes go, your best bet (and probably the quick answer you’ll get from Magento support) will be to disable the persistant cart feature for the default configuration setting, but then enable it for specific stores that need it. This will let carts

Coming up with a fix on your own is going to be uncharted territory, and I can’t think of a way to do it that isn’t terribly hacky/unstable. The most straight forward way would be a class rewrite on the synchronizePersistentInf that calls it’s parent method unless you’ve detected this is an API request.