Description

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

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

class foo {private$sum =0;functionSum($num) {return$this->sum +=$num;  }}$server =newsoapserver(null,array('uri'=>"http://testuri.org"));$server->setclass("foo");$server->setpersistence(SOAP_PERSISTENCE_SESSION);

When we useSOAP_PERSISTENCE_SESSION, it will silently fail ifsession 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 thatsession.so is loaded when we use the feature
• throw an exception whensetPersistence() 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