Underline in hosts url messes up ClientBuilder

[slobo]

Summary of problem or feature request

Full URLs with with underline (_) in hostname don't get parsed properly by the ClientBuilder. This is because of usage of FILTER_VALIDATE_URL in ClientBuilder::prependMissingScheme - it incorrectly prepends another 'http://' to the url.

Seems PHP people can't quite agree if _ should be allowed in hostnames (https://bugs.php.net/bug.php?id=64948) but since in practice one can indeed have http://host_name.example.com and DNS and browsers will think nothing bad of it, I think ClientBuilder needs to work around the limitation in PHP.

Code snippet of problem

    $client = ClientBuilder::create()
      ->setHosts([ 'http://host_name.example.com:80' ])
      ->build();

   // endpoint becomes http://http:9200//host_name.example.com:80

System details

• Operating System Linux
• PHP Version 5.6.19
• ES-PHP client version v2.2.1

[polyfractal]

Just FYI, going to tag a release soon with the "extended" host configuration which, while it doesn't solve the issue, should make it tolerable for now.

[polyfractal]

Just tagged v2.2.2, which has this extended host configuration syntax. You can read more about the syntax here: https://www.elastic.co/guide/en/elasticsearch/client/php-api/2.0/_configuration.html#_extended_host_configuration

Sample:

$hosts = [
    // This is effectively equal to: "https://username:password!#$?*[email protected]:9200/"
    [
        'host' => 'foo.com',
        'port' => '9200',
        'scheme' => 'https',
        'user' => 'username',
        'password' => 'password!#$?*abc'
    ],

    // This is equal to "http://localhost:9200/"
    [
        'host' => 'localhost',    // Only host is required
    ]
];
$client = ClientBuilder::create()           // Instantiate a new ClientBuilder
                    ->setHosts($hosts)      // Set the hosts
                    ->build();              // Build the client object

The values provided via the "extended" syntax aren't validated at all, so you can basically use any characters, encoding, etc that you wish, even if they aren't strictly legal or permitted by the RFCs.

Hope this helps! I'd like to make the "inline" syntax more robust in the future, but it appears to be a larger project than I had hoped, so it may have to wait for the next major version.

[polyfractal]

Closing, please feel free to reopen if the extended syntax doesn't fix this for you! Thanks for the report :)