|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44248 RFC2616 transgression while HTTPS request through proxy with SoapClient object
Submitted: 2008-02-25 22:03 UTC Modified: 2010-10-05 13:44 UTC
Avg. Score:5.0 ± 0.0
Reproduced:12 of 12 (100.0%)
Same Version:5 (41.7%)
Same OS:6 (50.0%)
From: jboffel at gmail dot com Assigned: dmitry (profile)
Status: Closed Package: SOAP related
PHP Version: 5.2.9 OS: Linux RedHat Enterprise
Private report: No CVE-ID: None
 [2008-02-25 22:03 UTC] jboffel at gmail dot com
Configure line :
No need for a configure line here, just need the php extension

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

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)
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 :

$client = new SoapClient("some.wsdl", array('proxy_host'=>"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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-04-28 18:36 UTC]
Please try using this CVS snapshot:
For Windows:

 [2009-04-28 19:47 UTC] 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-30 07:58 UTC] jboffel at gmail dot com
I'll even give you a link on another bug related to our problem :

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-05-02 12:10 UTC] 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-06-16 08:15 UTC] 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-09-01 17:02 UTC]
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:

Connection: Keep-Alive
User-Agent: PHP-SOAP/5.2.11RC2-dev
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
Content-Length: 552

<?xml version="1.0" encoding="UTF-8"?>... etc. etc.

Please reopen this bug if you still have this problem.
 [2009-09-01 17:11 UTC]
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:14 UTC] jboffel at gmail dot com

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 18:43 UTC]
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 18:55 UTC] 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-09 19:46 UTC]
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-09 20:55 UTC] jboffel at gmail dot com
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.
 [2009-09-10 08:29 UTC]
Dmitry, you seem to be the expert on SOAP/HTTP connecting. Can you take this bug?
 [2010-10-05 13:44 UTC]
Automatic comment from SVN on behalf of dmitry
Log: Fixed bug #44248 (RFC2616 transgression while HTTPS request through proxy with SoapClient object).
 [2010-10-05 13:44 UTC]
-Status: Assigned +Status: Closed
 [2010-10-05 13:44 UTC]
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jun 25 14:01:31 2024 UTC