Description

I'm not sure if it's the bug or a feature request.

Basically, I found the problem in ext/soap/tests/server009.phpt

class foo {
  private $sum = 0;

  function Sum($num) {
    return $this->sum += $num;
  }
}

$server = new soapserver(null,array('uri'=>"http://testuri.org"));
$server->setclass("foo");
$server->setpersistence(SOAP_PERSISTENCE_SESSION);

When we use SOAP_PERSISTENCE_SESSION, it will silently fail if session is built as a shared library. It may be a common case for distribution of Linux - they tend to offer extensions separately from the language core.

The check for this value is protected by guards (link)

#if defined(HAVE_PHP_SESSION) && !defined(COMPILE_DL_SESSION)
			/* If session then update session hash with new object */
			if (service->soap_class.persistence == SOAP_PERSISTENCE_SESSION) {
				zval *session_vars = &PS(http_session_vars), *tmp_soap_p;
...
			} else {
				soap_obj = &tmp_soap;
			}
#else

I'm not sure what is the best way to improve this, we can probably:

• make sure that session.so is loaded when we use the feature
• throw an exception when setPersistence() is called with an impossible argument
• trigger a warning telling the user that this not gonna work

I reckon, at least we should raise the warning - otherwise it may be quite confusing for the user