Bug #50997 [Com]: SOAP Error when trying to submit 2nd Element of a choice
Edit report at https://bugs.php.net/bug.php?id=50997&edit=1
ID: 50997
Comment by: jboffel at gmail dot com
Reported by:mrsharp at gmx dot de
Summary:SOAP Error when trying to submit 2nd Element of a
choice
Status: Open
Type: Bug
Package:SOAP related
Operating System: debian
PHP Version:5.2.12
Block user comment: N
Private report: N
New Comment:
Hi,
I'll give a try to help to solve that bug.
I think I identified the problem.
Algorythm for choice validation is :
- Enter choice element
- Take first sequence sub element
- Try to match list of elements against properties given to the function
- If fail (like in that example because we use element code instead of the
sequence) => pass to second choice
- Try to match list of elements...
- Success !
- return OK
And that is correctly implemented for what I saw in the soap_encoding.c file in
source code of PHP extension.
However, I guess the problem is located in the part of the function analysing
the node element of the chain.
If one of the mandatory parameters are note matched, that part of function will
generate a php_error with E_ERROR severity level, I guess it's raising
exception immediatly in the PHP engine and so it's stopping execution of the
algorythm.
To try to solve partialy that problem, we can see that the strict parameter is
set to 0 at sub call of model_to_xml_object from a choice segment.
case XSD_CONTENT_CHOICE: {
sdlContentModelPtr *tmp;
HashPosition pos;
int ret = 0;
zend_hash_internal_pointer_reset_ex(model->u.content,
&pos);
while (zend_hash_get_current_data_ex(model->u.content,
(void**)&tmp, &pos) == SUCCESS) {
int tmp_ret = model_to_xml_object(node, *tmp,
object, style, 0 TSRMLS_CC);
if (tmp_ret == 1) {
return 1;
} else if (tmp_ret != 0) {
ret = 1;
}
zend_hash_move_forward_ex(model->u.content,
&pos);
}
return ret;
}
However, I think it is not enough, if choice content not only element but also
sequence or list or union or any other groupment of element, it will pass the
element in that group with it's normal strict level. Not with 0, so it will
produce the error log raisin the exception.
Solution could be to try to propagate the strict property to 0 if coming from
choice segment, but have to do that on all other segment of code for group type
xml tag...
I succeed to confirm my theory by using same example than above but like that :
$params = array('firstName' => 'foo', 'surName' => 'fooBar');
$soapClient->newOperation($params);
In that case, first iteration will pass the element without problem as the
stric parameter has been forced to 0 and then when it will reach second
iteration with the sequence it will match against our parameters.
So if you only have element in your choice or only element and at end something
group type of element, it will work. Not if group type of element is somewhere
else.
Reason is, I believe, because of group of elements are not type by themself.
Sequence, union and list are not type. It doesn't make sense to pass them to
srict or not strict in a choise case. When you make your array or parameters
thoses levels dosen't appear. You don't need to create a key sequence to make
it work. It's just usefull for schema interpretation.
It's leading me to other part of the problem. If we propagate strict value to 0
to each sub element of a sequence, it will obviously work, but will not really
follow the schema as well. You could describe a schema with mandatory elements
in a sequence even the sequence can be ignored by the choice legaly.
Exemple :
You'd like to get an error if someone try to use the second choice and forget
to put a paremeter age. It woudln't work if you propagate the strict parameter
to value 0 to the element node matching...
It's meaning it is legal is this situation to fail to find a matching choice.
So, ultimately it's lead to only one real solution to my eyes. Create a way to
disable the raise of php_error at element matching if we are in a choice
process.
Previous Comments:
[2012-05-24 12:20:21] potgieterg at gmail dot com
The above exam
Bug #47492 [Com]: SOAP_SINGLE_ELEMENT_ARRAYS has no effect
Edit report at https://bugs.php.net/bug.php?id=47492&edit=1
ID: 47492
Comment by: jboffel at gmail dot com
Reported by:florian dot eberle at gmail dot com
Summary:SOAP_SINGLE_ELEMENT_ARRAYS has no effect
Status: Feedback
Type: Bug
Package:SOAP related
Operating System: Debian Lenny
PHP Version:5.2CVS-2009-02-24 (CVS)
Block user comment: N
Private report: N
New Comment:
Hi all,
I think for people without WSDL, you shouldn't expect
SOAP_SINGLE_ELEMENT_ARRAYS to work.
To know it, SoapClient need a XSD saying it could be or not more than one
result to decide it must be in array or not.
Just with SOAP answer it is technically impossible to make a difference between
an anwser that is just 1 element but could have N and an answer that is known
to be only 1.
Exemple :
age: 17
age: 17
sister : 1
In first case, if you don't have a XSD to say brotherdetail is a type and have
rule maxOccurs = unbounded, how do you expect SoapClient will know it could
have been more than one detail ?
Of course with second example, SoapClient will now it could be because it'll
find more than one so it will naturally make an array...
Previous Comments:
[2010-11-04 08:08:54] timothee dot groleau at mig33global dot com
Oh duh, I forgot to add some version information:
$ php -version
PHP 5.3.3 (cli) (built: Oct 29 2010 14:24:39)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I'm on Mac OS, php was installed from macports
[2010-11-04 07:55:50] timothee dot groleau at mig33global dot com
Same problem here. xsi:type="ns2:Vector" entries are not translated to arrays
if there is only one element inside. Example below:
soap client created like so:
$client = new soapclient(null, array(
'location' => $soap_ejb_service_url,
'uri' => $soap_ejb_service_name,
'features' => SOAP_SINGLE_ELEMENT_ARRAYS | SOAP_USE_XSI_ARRAY_TYPE,
'trace' => true)
);
$response = $client->__soapCall($function, $parameters);
raw soap response:
http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
http://schemas.xmlsoap.org/soap/encoding/";>
http://xml.apache.org/xml-soap"; xsi:type="ns2:Map">
totalpages
1.0
totalresults
1
chatrooms
name
tim_test
id
6
status
ACTIVE
language
ENG
page
1
$response returned by php client:
array(4) {
["totalpages"]=>
float(1)
["totalresults"]=>
int(1)
["chatrooms"]=>
object(stdClass)#2 (1) {
["item"]=>
array(16) {
["name"]=>
string(8) "tim_test"
["id"]=>
string(1) "6"
["status"]=>
string(6) "ACTIVE"
["language"]=>
string(3) "ENG"
}
}
["page"]=>
int(1)
}
[2010-06-20 21:27:41] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-11-27 13:45:55] niek at signet dot nl
This bug was filed a long time ago, still no replies. Is there going to be some
kind of fix for this?
[2009-11-27 08:35:52] niek at signet dot nl
I've the same problem; but I use WSDL with my SOAP.
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
https://bugs.php.net/bug.php?id=47492
--
Edit this bug report at https://bugs.php.net/bug.php?id=47492&edit=1
#44248 [Ver]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248 User updated by: jboffel at gmail dot com Reported By: jboffel at gmail dot com Status: Verified Bug Type: SOAP related Operating System: Linux RedHat Enterprise PHP Version: 5.2.9 New Comment: Did you test to use Apache like web server or like proxy ? I had problem when used like proxy with Apache 1.3 You should get a 400 Bad Request error status code... The only case it could not return error is if the host is in fact an IP. In that case host parameter is supposed to be sent empty so it's possible they decided to accept without complaining requests in this particular case. Previous Comments: [2009-09-09 19:46:28] sjo...@php.net Could reproduce. The SoapClient does indeed not send a Host parameter when doing a CONNECT, which is a bug because the RFC says it should. However, this causes no problems with any version of Apache I tried (1.3, 2.0, 2.2). [2009-09-01 18:55:53] jboffel at gmail dot com The thing is that Apache server follow the RFC and really block (voluntarily that is not a bug) the request (there is no workaround to force Apache to do the job or I didn't find it). You can see in the error log file that Apache ask us to follow the RFC and add the Host parameter. So basically Apache used as a proxy doesn't really "need" Host parameter but it's to avoid bug when connecting, or example, to an Apache web server which uses VirtualHost based certificates configurations with HTTPS connections... So yes it's only linked to the RFC. [2009-09-01 18:43:54] sjo...@php.net Does the Apache proxy really need the Host header? Is this bug a problem other than that it does not conform with the RFC? -------- [2009-09-01 17:14:32] jboffel at gmail dot com Hi, Thanks for your test, but you have to do it through HTTPS connection to reproduce the bug. In fact, the bug is linked to the use of an Apache proxy through HTTPS connection and a SOAP call. If you connect through HTTP you don't do the CONNECT command and you can't see the bug. [2009-09-01 17:11:14] sjo...@php.net I misunderstood the problem. The request I posted was for HTTP, not for HTTPS. For HTTPS, the Host header is indeed missing. I am not yet sure that that is a bug. 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/44248 -- Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [Opn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248 User updated by: jboffel at gmail dot com Reported By: jboffel at gmail dot com Status: Open Bug Type: SOAP related Operating System: Linux RedHat Enterprise PHP Version: 5.2.9 New Comment: The thing is that Apache server follow the RFC and really block (voluntarily that is not a bug) the request (there is no workaround to force Apache to do the job or I didn't find it). You can see in the error log file that Apache ask us to follow the RFC and add the Host parameter. So basically Apache used as a proxy doesn't really "need" Host parameter but it's to avoid bug when connecting, or example, to an Apache web server which uses VirtualHost based certificates configurations with HTTPS connections... So yes it's only linked to the RFC. Previous Comments: [2009-09-01 18:43:54] sjo...@php.net Does the Apache proxy really need the Host header? Is this bug a problem other than that it does not conform with the RFC? ---- [2009-09-01 17:14:32] jboffel at gmail dot com Hi, Thanks for your test, but you have to do it through HTTPS connection to reproduce the bug. In fact, the bug is linked to the use of an Apache proxy through HTTPS connection and a SOAP call. If you connect through HTTP you don't do the CONNECT command and you can't see the bug. [2009-09-01 17:11:14] sjo...@php.net I misunderstood the problem. The request I posted was for HTTP, not for HTTPS. For HTTPS, the Host header is indeed missing. I am not yet sure that that is a bug. [2009-09-01 17:02:47] sjo...@php.net Thank you for your bug report. I could not reproduce your problem. It is possible it has already been fixed in the meantime. This is the request the SoapClient sends to the proxy server in my setup: POST http://ws1.webservices.nl:80/address/soap.php HTTP/1.1 Host: ws1.webservices.nl Connection: Keep-Alive User-Agent: PHP-SOAP/5.2.11RC2-dev Content-Type: text/xml; charset=utf-8 SOAPAction: "http://ws1.webservices.nl/address/soap.php/addressReeksPostcodeSearch"; Content-Length: 552 ... etc. etc. Please reopen this bug if you still have this problem. [2009-06-16 08:15:35] garyxemily at hotmail dot co dot uk gary the 4 ed mam is called jaki rolo she is the last dinosour in the world if u see her phone the millatery :D 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/44248 -- Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [Opn->Bgs]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248
User updated by: jboffel at gmail dot com
Reported By: jboffel at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SOAP related
Operating System: Linux RedHat Enterprise
PHP Version: 5.2.9
New Comment:
Hi,
Thanks for your test, but you have to do it through HTTPS connection to
reproduce the bug.
In fact, the bug is linked to the use of an Apache proxy through HTTPS
connection and a SOAP call. If you connect through HTTP you don't do the
CONNECT command and you can't see the bug.
Previous Comments:
[2009-09-01 17:11:14] sjo...@php.net
I misunderstood the problem. The request I posted was for HTTP, not for
HTTPS. For HTTPS, the Host header is indeed missing. I am not yet sure
that that is a bug.
[2009-09-01 17:02:47] sjo...@php.net
Thank you for your bug report.
I could not reproduce your problem. It is possible it has already been
fixed in the meantime.
This is the request the SoapClient sends to the proxy server in my
setup:
POST http://ws1.webservices.nl:80/address/soap.php HTTP/1.1
Host: ws1.webservices.nl
Connection: Keep-Alive
User-Agent: PHP-SOAP/5.2.11RC2-dev
Content-Type: text/xml; charset=utf-8
SOAPAction:
"http://ws1.webservices.nl/address/soap.php/addressReeksPostcodeSearch";
Content-Length: 552
... etc. etc.
Please reopen this bug if you still have this problem.
[2009-06-16 08:15:35] garyxemily at hotmail dot co dot uk
gary the 4 ed mam is called jaki rolo she is the last dinosour in the
world if u see her phone the millatery :D
[2009-05-02 12:10:19] jboffel at gmail dot com
sorry small mistake on my previous comment...
Good fix is:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
smart_str_append_const(&soap_headers, "\r\n");
--------------------
[2009-04-30 07:58:36] jboffel at gmail dot com
I'll even give you a link on another bug related to our problem :
http://bugs.php.net/bug.php?id=30359
This bug show us that "Host: " field was previously in the code (in
2004) and there was a bug on this field (about the port) which complet
my fix to avoid repeating his bug.
So apparently you need to add this code to be compliant to all RFC
requests:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
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/44248
--
Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [Opn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248
User updated by: jboffel at gmail dot com
Reported By: jboffel at gmail dot com
Status: Open
Bug Type: SOAP related
Operating System: Linux RedHat Enterprise
PHP Version: 5.2.9
New Comment:
sorry small mistake on my previous comment...
Good fix is:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
smart_str_append_const(&soap_headers, "\r\n");
Previous Comments:
--------------------
[2009-04-30 07:58:36] jboffel at gmail dot com
I'll even give you a link on another bug related to our problem :
http://bugs.php.net/bug.php?id=30359
This bug show us that "Host: " field was previously in the code (in
2004) and there was a bug on this field (about the port) which complet
my fix to avoid repeating his bug.
So apparently you need to add this code to be compliant to all RFC
requests:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
[2009-04-28 19:47:01] jboffel at gmail dot com
I checked source code of last CVS snapshot you gave with your link.
I can't easily test in same conditions than before so I just compared
source code.
I could be wrong but I'm pretty sure there is no difference and that
the bug is still present.
smart_str_append_const(&soap_headers, "CONNECT ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_appendc(&soap_headers, ':');
smart_str_append_unsigned(&soap_headers, phpurl->port);
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
proxy_authentication(this_ptr, &soap_headers TSRMLS_CC);
smart_str_append_const(&soap_headers, "\r\n");
proxy_authentication just add basic auth if necessary. Nothing to do
with "Host: " header parameter.
And it's still in HTTP/1.1, so for me, no news.
[2009-04-28 18:36:31] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-02-25 22:03:51] jboffel at gmail dot com
Description:
Configure line :
No need for a configure line here, just need the php extension soap.so
Setup :
You have to make a soap call on an https based webservice through an
Apache proxy (Apache or any proxy which is following rfc2616).
Explanation :
When you make an HTTPS connection in HTTP/1.1 through a proxy you MUST
include an host parameter in the HTTP header like that :
CONNECT uri-test:443 HTTP/1.1
Host: uri-test
And what's done today is :
CONNECT uri-test:443 HTTP/1.1
So we're clearly missing the Host parameter like explaining below,
rfc2616 require this :
A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI does not include an Internet host
name for the service being requested, then the Host header field
MUST
be given with an empty value. An HTTP/1.1 proxy MUST ensure that
any
request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad
Request)
status code to any HTTP/1.1 request message which lacks a Host
header
field.
The problem is based in php_http.c in ext/soap/ of ANY existing version
of PHP (not only 5.2.5)
Well, there is two possible fix at least :
1) Add after line 169 :
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
The problem here is that I'm NOT sure that every time in HTTPS
connection we need to put exactly the value of phpurl-host.
For example I don't know if it's possible to be in a situation like
this : (IP like x.x.x.x)
CONNECT IP:443 HTTP/1.1
Host: www.test.com
If yes, this fix is not perfect.
2) Modify line 169 from :
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
to :
smart_str_append_const(&soap_headers, " HTTP/1.0\r\n");
Of course solution 2 force us to downgrade to protocol HTTP/1.0 which
won't be able to access HTTPS virtualhosted website on a sing
#44248 [Opn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248
User updated by: jboffel at gmail dot com
Reported By: jboffel at gmail dot com
Status: Open
Bug Type: SOAP related
Operating System: Linux RedHat Enterprise
PHP Version: 5.2.5
New Comment:
I'll even give you a link on another bug related to our problem :
http://bugs.php.net/bug.php?id=30359
This bug show us that "Host: " field was previously in the code (in
2004) and there was a bug on this field (about the port) which complet
my fix to avoid repeating his bug.
So apparently you need to add this code to be compliant to all RFC
requests:
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
if (phpurl->port != 80) {
smart_str_append_const(&soap_headers, ":");
smart_str_append_unsigned(&soap_headers, phpurl->port);
}
Previous Comments:
--------------------
[2009-04-28 19:47:01] jboffel at gmail dot com
I checked source code of last CVS snapshot you gave with your link.
I can't easily test in same conditions than before so I just compared
source code.
I could be wrong but I'm pretty sure there is no difference and that
the bug is still present.
smart_str_append_const(&soap_headers, "CONNECT ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_appendc(&soap_headers, ':');
smart_str_append_unsigned(&soap_headers, phpurl->port);
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
proxy_authentication(this_ptr, &soap_headers TSRMLS_CC);
smart_str_append_const(&soap_headers, "\r\n");
proxy_authentication just add basic auth if necessary. Nothing to do
with "Host: " header parameter.
And it's still in HTTP/1.1, so for me, no news.
[2009-04-28 18:36:31] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2008-02-25 22:03:51] jboffel at gmail dot com
Description:
Configure line :
No need for a configure line here, just need the php extension soap.so
Setup :
You have to make a soap call on an https based webservice through an
Apache proxy (Apache or any proxy which is following rfc2616).
Explanation :
When you make an HTTPS connection in HTTP/1.1 through a proxy you MUST
include an host parameter in the HTTP header like that :
CONNECT uri-test:443 HTTP/1.1
Host: uri-test
And what's done today is :
CONNECT uri-test:443 HTTP/1.1
So we're clearly missing the Host parameter like explaining below,
rfc2616 require this :
A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI does not include an Internet host
name for the service being requested, then the Host header field
MUST
be given with an empty value. An HTTP/1.1 proxy MUST ensure that
any
request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad
Request)
status code to any HTTP/1.1 request message which lacks a Host
header
field.
The problem is based in php_http.c in ext/soap/ of ANY existing version
of PHP (not only 5.2.5)
Well, there is two possible fix at least :
1) Add after line 169 :
smart_str_append_const(&soap_headers, "Host: ");
smart_str_appends(&soap_headers, phpurl->host);
smart_str_append_const(&soap_headers, "\r\n");
The problem here is that I'm NOT sure that every time in HTTPS
connection we need to put exactly the value of phpurl-host.
For example I don't know if it's possible to be in a situation like
this : (IP like x.x.x.x)
CONNECT IP:443 HTTP/1.1
Host: www.test.com
If yes, this fix is not perfect.
2) Modify line 169 from :
smart_str_append_const(&soap_headers, " HTTP/1.1\r\n");
to :
smart_str_append_const(&soap_headers, " HTTP/1.0\r\n");
Of course solution 2 force us to downgrade to protocol HTTP/1.0 which
won't be able to access HTTPS virtualhosted website on a single IP
address.
Reproduce code:
---
Short script :
"localhost",
'proxy_port'=>
8080,'uri'=>"https://test-uri/";));
$client->SomeFunction($a, $b, $c);
?>
Expected result:
HTTP header like that :
CONNECT uri-test:443 HTTP/1.1
Host: uri-test
Actual result:
--
CONNECT uri-test:443 HTTP/1.1
--
Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [Fbk->Opn]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
ID: 44248 User updated by: jboffel at gmail dot com Reported By: jboffel at gmail dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: Linux RedHat Enterprise PHP Version: 5.2.5 New Comment: I checked source code of last CVS snapshot you gave with your link. I can't easily test in same conditions than before so I just compared source code. I could be wrong but I'm pretty sure there is no difference and that the bug is still present. smart_str_append_const(&soap_headers, "CONNECT "); smart_str_appends(&soap_headers, phpurl->host); smart_str_appendc(&soap_headers, ':'); smart_str_append_unsigned(&soap_headers, phpurl->port); smart_str_append_const(&soap_headers, " HTTP/1.1\r\n"); proxy_authentication(this_ptr, &soap_headers TSRMLS_CC); smart_str_append_const(&soap_headers, "\r\n"); proxy_authentication just add basic auth if necessary. Nothing to do with "Host: " header parameter. And it's still in HTTP/1.1, so for me, no news. Previous Comments: [2009-04-28 18:36:31] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ ---------------- [2008-02-25 22:03:51] jboffel at gmail dot com Description: Configure line : No need for a configure line here, just need the php extension soap.so Setup : You have to make a soap call on an https based webservice through an Apache proxy (Apache or any proxy which is following rfc2616). Explanation : When you make an HTTPS connection in HTTP/1.1 through a proxy you MUST include an host parameter in the HTTP header like that : CONNECT uri-test:443 HTTP/1.1 Host: uri-test And what's done today is : CONNECT uri-test:443 HTTP/1.1 So we're clearly missing the Host parameter like explaining below, rfc2616 require this : A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. The problem is based in php_http.c in ext/soap/ of ANY existing version of PHP (not only 5.2.5) Well, there is two possible fix at least : 1) Add after line 169 : smart_str_append_const(&soap_headers, "Host: "); smart_str_appends(&soap_headers, phpurl->host); smart_str_append_const(&soap_headers, "\r\n"); The problem here is that I'm NOT sure that every time in HTTPS connection we need to put exactly the value of phpurl-host. For example I don't know if it's possible to be in a situation like this : (IP like x.x.x.x) CONNECT IP:443 HTTP/1.1 Host: www.test.com If yes, this fix is not perfect. 2) Modify line 169 from : smart_str_append_const(&soap_headers, " HTTP/1.1\r\n"); to : smart_str_append_const(&soap_headers, " HTTP/1.0\r\n"); Of course solution 2 force us to downgrade to protocol HTTP/1.0 which won't be able to access HTTPS virtualhosted website on a single IP address. Reproduce code: --- Short script : "localhost", 'proxy_port'=> 8080,'uri'=>"https://test-uri/";)); $client->SomeFunction($a, $b, $c); ?> Expected result: HTTP header like that : CONNECT uri-test:443 HTTP/1.1 Host: uri-test Actual result: -- CONNECT uri-test:443 HTTP/1.1 -- Edit this bug report at http://bugs.php.net/?id=44248&edit=1
#44248 [NEW]: RFC2616 transgression while HTTPS request through proxy with SoapClient object
From: jboffel at gmail dot com Operating system: Linux RedHat Enterprise PHP version: 5.2.5 PHP Bug Type: SOAP related Bug description: RFC2616 transgression while HTTPS request through proxy with SoapClient object Description: Configure line : No need for a configure line here, just need the php extension soap.so Setup : You have to make a soap call on an https based webservice through an Apache proxy (Apache or any proxy which is following rfc2616). Explanation : When you make an HTTPS connection in HTTP/1.1 through a proxy you MUST include an host parameter in the HTTP header like that : CONNECT uri-test:443 HTTP/1.1 Host: uri-test And what's done today is : CONNECT uri-test:443 HTTP/1.1 So we're clearly missing the Host parameter like explaining below, rfc2616 require this : A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. The problem is based in php_http.c in ext/soap/ of ANY existing version of PHP (not only 5.2.5) Well, there is two possible fix at least : 1) Add after line 169 : smart_str_append_const(&soap_headers, "Host: "); smart_str_appends(&soap_headers, phpurl->host); smart_str_append_const(&soap_headers, "\r\n"); The problem here is that I'm NOT sure that every time in HTTPS connection we need to put exactly the value of phpurl-host. For example I don't know if it's possible to be in a situation like this : (IP like x.x.x.x) CONNECT IP:443 HTTP/1.1 Host: www.test.com If yes, this fix is not perfect. 2) Modify line 169 from : smart_str_append_const(&soap_headers, " HTTP/1.1\r\n"); to : smart_str_append_const(&soap_headers, " HTTP/1.0\r\n"); Of course solution 2 force us to downgrade to protocol HTTP/1.0 which won't be able to access HTTPS virtualhosted website on a single IP address. Reproduce code: --- Short script : "localhost", 'proxy_port'=> 8080,'uri'=>"https://test-uri/";)); $client->SomeFunction($a, $b, $c); ?> Expected result: HTTP header like that : CONNECT uri-test:443 HTTP/1.1 Host: uri-test Actual result: -- CONNECT uri-test:443 HTTP/1.1 -- Edit bug report at http://bugs.php.net/?id=44248&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44248&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44248&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44248&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44248&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44248&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44248&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44248&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44248&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44248&r=support Expected behavior:http://bugs.php.net/fix.php?id=44248&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44248&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44248&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44248&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44248&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44248&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44248&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44248&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44248&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44248&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44248&r=mysqlcfg
