|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #63519 Incorrect handle of HTTPS request through proxy using SNI
Submitted: 2012-11-14 17:22 UTC Modified: 2021-06-13 04:22 UTC
Avg. Score:3.8 ± 1.1
Reproduced:16 of 19 (84.2%)
Same Version:4 (25.0%)
Same OS:2 (12.5%)
From: marco at csita dot unige dot it Assigned: cmb (profile)
Status: No Feedback Package: Streams related
PHP Version: 5.3.18 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: marco at csita dot unige dot it
New email:
PHP Version: OS:


 [2012-11-14 17:22 UTC] marco at csita dot unige dot it
The http wrapper allow streams to access to remote file using the HTTPS (HTTP over SSL/TLS) protocol and supports passing request through HTTP proxy.

Unfortunately, SSL-related options and HTTP proxy option are handled by different contexts, unaware each of the other. Thus, from the point of view of SSL, the stream is connected to the proxy, while from the point of view of HTTP the stream is connected to the remote web server.

Using default setting, this produces a mismatch between the value in the SNI_server_name indicator, which reports the proxy host name, and the HTTP header Host:, which reports the web server host name. As result, web servers with support for SNI handle incorrectly the request or (e.g. Apache) raise a 400 error. 

Test script:
Suppose you need to access to the remote URL using the proxy

This is the code fragment:

$path = '';

$opts = array(
  'http' => array(
    'method' => 'GET',
    'proxy' => 'tcp://',

$context = stream_context_create($opts);
$fp = fopen($path, 'r', false, $context);
$meta = stream_get_meta_data($fp);

Expected result:
It would advisable that the stream module could detect and handle automatically this situation.

A workaround is to explicitly set the web server host name in the SNI field:

$path = '';
$hostname = parse_url($path, PHP_URL_HOST);

$opts = array(
  'http' => array(
    'method' => 'GET',
    'proxy' => 'tcp://',
  'ssl' => array(
    'SNI_server_name' => $hostname,
    'SNI_enabled' => TRUE,

Actual result:
If the web server is an Apache httpd 2.2.12 or later , it results:

    [wrapper_data] => Array
            [0] => HTTP/1.1 400 OK

with a line such as:

[Thu Nov ...] [error] Hostname provided via SNI and hostname provided via HTTP are different

in the error log of the web server.
The behaviour of other web server implementations can vary.

If you have not an access to a Apache web server configured to use SNI, you can emulate a web server using a recent OpenSSL with self-signed certificates and starting with command:

C:\>openssl s_server -key server.key -cert server.crt -accept 8443 -www -tlsextdebug

The value in the SNI field will be well recognizable in the dump.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-10-14 13:56 UTC] samuel dot vogel at viison dot com
Setting 'SNI_enabled' in the stream context is also a workaround if it's not required by the server.
 [2021-06-02 16:25 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-06-02 16:25 UTC]
Is this still an issue with any of the actively supported PHP

[1] <>
 [2021-06-13 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed May 22 22:01:32 2024 UTC