#34746 [Com]: SOAP_PERSISTENCE_SESSION no longer works
ID: 34746
Comment by: mir at miras dot org
Reported By: brent at jeneral dot com
Status: No Feedback
Bug Type: SOAP related
Operating System: Freebsd 5.4
PHP Version: 5.0.5
New Comment:
Hi,
I would like this to be reopened because I have the same problems:
loke:~/Projekter/php/soap/basic$ dpkg -s php5.0
Package: php5.0
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 20
Maintainer: Piotr Roszatycki [EMAIL PROTECTED]
Architecture: all
Version: 5.0.5-0.8
Provides: php5
Server:
?php
session_start();
class HelloServer {
private $count;
function __construct() {
$this-count = 0;
}
function sayhello() {
$this-count++;
return $this-count;
}
}
$options = array(uri = http://test-uri/;);
$server = new SoapServer(NULL, $options);
$server-setClass(HelloServer);
$server-setPersistence(SOAP_PERSISTENCE_SESSION);
$server-handle();
?
Client:
?php
function format($s)
{
$s = str_replace(, \n, $s);
return pre . htmlspecialchars($s) . /pre;
}
print htmlheadtitleSession Test/title/headbody;
$option = array(
location =
http://localhost/~mir/soap/php5/session/soapSessionServer.php;,
uri = http://test-uri/;,
trace = 1);
$client = new SoapClient(NULL, $option);
$arg = array();
try
{
$response = $client-__soapCall(sayhello, $arg);
print pResponse:br$response/p;
}
catch(SoapFault $sf)
{
print pResponse:br . $sf-getMessage() . /p\n;
}
print format($client-__getLastRequestHeaders()) . \n;
print format($client-__getLastRequest()) . \n;
print format($client-__getLastResponseHeaders()) . \n;
print format($client-__getLastResponse()) . \n;
print /body/html;
?
Output - first time rune:
HTTP/1.1 200 OK
Date: Tue, 01 Nov 2005 23:05:25 GMT
Server: Apache/2.0.55 (Debian) mod_python/3.1.3 Python/2.3.5
PHP/5.0.5-Debian-0.8 mod_perl/2.0.1 Perl/v5.8.7
X-Powered-By: PHP/5.0.5-Debian-0.8
Set-Cookie: PHPSESSID=c6d215abd0930d3c48bb82dc9645b8ea; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Content-Length: 505
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Output - second time:
HTTP/1.1 200 OK
Date: Tue, 01 Nov 2005 23:23:09 GMT
Server: Apache/2.0.55 (Debian) mod_python/3.1.3 Python/2.3.5
PHP/5.0.5-Debian-0.8 mod_perl/2.0.1 Perl/v5.8.7
X-Powered-By: PHP/5.0.5-Debian-0.8
Set-Cookie: PHPSESSID=94b0f37c8de99c263a74b3f657d12f3a; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Content-Length: 505
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
As can be seen the session id changes for every call. Looking for the
cookie on the client shows the problem - the cookie is never stored on
the client so succeding invocations does not send any session id back
which causes the server to think this is a new session.
Previous Comments:
[2005-10-21 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-10-17 21:06:56] justin at eckhouse dot com
I seem to be having the same issue, both with 5.0.5 and 5.1RC1 when
using SOAP_PERSISTENCE_SESSION.
- Justin
[2005-10-13 10:55:07] [EMAIL PROTECTED]
I don't get how changing this line can help to fix the problem.
Imagine that you've build PHP with SOAP enabled and after that you've
additionally built session module.
Both of them would be available, but SOAP wouldn't know about session.
In FreeBSD all extensions are dinamically loaded, so the
persistence session support cannot work anymore.
This is the weirdest way to build PHP I've seen, which creates a lot of
troubles for users and doesn't solve any problems.
I've already saw a lot of confusion from FreeBSD users that install PHP
and discover that none of the modules (that are usually enabled by
default) are there.
[2005-10-13 08:19:15] ale at FreeBSD dot org
I think the problem is this: in soap.c you changed all the following
rows
#if HAVE_PHP_SESSION
with
#if HAVE_PHP_SESSION !defined(COMPILE_DL_SESSION)
In FreeBSD all extensions are dinamically loaded, so the persistence
session support cannot work anymore. Moreover, in FreeBSD,
#34746 [Com]: SOAP_PERSISTENCE_SESSION no longer works
ID: 34746
Comment by: mir at miras dot org
Reported By: brent at jeneral dot com
Status: Open
Bug Type: SOAP related
Operating System: Freebsd 5.4
PHP Version: 5.0.5
New Comment:
Now it gets spookie.
I downgraded from the php5-5.0.5 from the maintainer of php5 on Debian
to the official php5-5.0.5 in Sid and in this version it works. Checked
soap.c in the official version with my former version and the showed to
be identical!
Previous Comments:
[2005-11-02 01:17:36] brent at jeneral dot com
The workaround is to change all
#if HAVE_PHP_SESSION !defined(COMPILE_DL_SESSION)
back to
#if HAVE_PHP_SESSION
in soap.c
I agree that this is an ongoing issue. It seems as though there's an
unresolved discussion as to who owns the problem.
[2005-11-02 00:59:11] mir at miras dot org
Hi,
I would like this to be reopened because I have the same problems:
loke:~/Projekter/php/soap/basic$ dpkg -s php5.0
Package: php5.0
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 20
Maintainer: Piotr Roszatycki [EMAIL PROTECTED]
Architecture: all
Version: 5.0.5-0.8
Provides: php5
Server:
?php
session_start();
class HelloServer {
private $count;
function __construct() {
$this-count = 0;
}
function sayhello() {
$this-count++;
return $this-count;
}
}
$options = array(uri = http://test-uri/;);
$server = new SoapServer(NULL, $options);
$server-setClass(HelloServer);
$server-setPersistence(SOAP_PERSISTENCE_SESSION);
$server-handle();
?
Client:
?php
function format($s)
{
$s = str_replace(, \n, $s);
return pre . htmlspecialchars($s) . /pre;
}
print htmlheadtitleSession Test/title/headbody;
$option = array(
location =
http://localhost/~mir/soap/php5/session/soapSessionServer.php;,
uri = http://test-uri/;,
trace = 1);
$client = new SoapClient(NULL, $option);
$arg = array();
try
{
$response = $client-__soapCall(sayhello, $arg);
print pResponse:br$response/p;
}
catch(SoapFault $sf)
{
print pResponse:br . $sf-getMessage() . /p\n;
}
print format($client-__getLastRequestHeaders()) . \n;
print format($client-__getLastRequest()) . \n;
print format($client-__getLastResponseHeaders()) . \n;
print format($client-__getLastResponse()) . \n;
print /body/html;
?
Output - first time rune:
HTTP/1.1 200 OK
Date: Tue, 01 Nov 2005 23:05:25 GMT
Server: Apache/2.0.55 (Debian) mod_python/3.1.3 Python/2.3.5
PHP/5.0.5-Debian-0.8 mod_perl/2.0.1 Perl/v5.8.7
X-Powered-By: PHP/5.0.5-Debian-0.8
Set-Cookie: PHPSESSID=c6d215abd0930d3c48bb82dc9645b8ea; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Content-Length: 505
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
Output - second time:
HTTP/1.1 200 OK
Date: Tue, 01 Nov 2005 23:23:09 GMT
Server: Apache/2.0.55 (Debian) mod_python/3.1.3 Python/2.3.5
PHP/5.0.5-Debian-0.8 mod_perl/2.0.1 Perl/v5.8.7
X-Powered-By: PHP/5.0.5-Debian-0.8
Set-Cookie: PHPSESSID=94b0f37c8de99c263a74b3f657d12f3a; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Content-Length: 505
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/xml; charset=utf-8
As can be seen the session id changes for every call. Looking for the
cookie on the client shows the problem - the cookie is never stored on
the client so succeding invocations does not send any session id back
which causes the server to think this is a new session.
[2005-10-21 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-10-17 21:06:56] justin at eckhouse dot com
I seem to be having the same issue, both with 5.0.5 and 5.1RC1 when
using SOAP_PERSISTENCE_SESSION.
- Justin
[2005-10-13 10:55:07] [EMAIL PROTECTED]
I don't get how changing this line can help to fix the problem.
Imagine that you've build PHP with SOAP enabled and after that you've
additionally built session module.
Both of them would be available, but SOAP wouldn't know about session.
In FreeBSD all extensions are dinamically loaded, so the
#34746 [Com]: SOAP_PERSISTENCE_SESSION no longer works
ID: 34746 Comment by: justin at eckhouse dot com Reported By: brent at jeneral dot com Status: Feedback Bug Type: SOAP related Operating System: Freebsd 5.4 PHP Version: 5.0.5 New Comment: I seem to be having the same issue, both with 5.0.5 and 5.1RC1 when using SOAP_PERSISTENCE_SESSION. - Justin Previous Comments: [2005-10-13 10:55:07] [EMAIL PROTECTED] I don't get how changing this line can help to fix the problem. Imagine that you've build PHP with SOAP enabled and after that you've additionally built session module. Both of them would be available, but SOAP wouldn't know about session. In FreeBSD all extensions are dinamically loaded, so the persistence session support cannot work anymore. This is the weirdest way to build PHP I've seen, which creates a lot of troubles for users and doesn't solve any problems. I've already saw a lot of confusion from FreeBSD users that install PHP and discover that none of the modules (that are usually enabled by default) are there. [2005-10-13 08:19:15] ale at FreeBSD dot org I think the problem is this: in soap.c you changed all the following rows #if HAVE_PHP_SESSION with #if HAVE_PHP_SESSION !defined(COMPILE_DL_SESSION) In FreeBSD all extensions are dinamically loaded, so the persistence session support cannot work anymore. Moreover, in FreeBSD, extensions can use code provided by other shared extensions (like session.so in this case), so this check is actually a limitation for us. [2005-10-13 00:11:04] [EMAIL PROTECTED] Actually sniper asked you to try the certain snapshot, not some ports. Please do so. I'm not asking to do 'make install', btw. You can build it in your own directory and replace libphp5.so for 5 mins just to test it. I can't reproduce it, so I suspect it's already fixed, but I need you to comfirm it to be sure. [2005-10-13 00:03:22] brent at jeneral dot com FreeBSD's ports system uses patches to implement the products in it's framework. For some reason I cannot compile and integrate the lastest version. [2005-10-12 12:21:50] [EMAIL PROTECTED] What patches are you talking about? SOAP support requires only --enable-soap configure option. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34746 -- Edit this bug report at http://bugs.php.net/?id=34746edit=1
