Possible bug with PHP SDK openBucket() method

PHP SDK
1

Hi,

In the process of upgrading our PHP SDK to the latest with PHP7, we encountered an unknown error.

The error shows when I try to open a bucket. The error message is

LCB_EINVAL: Invalid input/arguments

We finally found out what was causing it. This is what I’ve found so far.

Works fine:

<?php

$cluster = new CouchbaseCluster('couchbaestest:8091');
$bucket = $cluster->openBucket('mybucket');
$doc = $bucket->get('docid');

Does not work (throws LCB_EINVAL error):

<?php

$cluster = new CouchbaseCluster('couchbaestest:8091?detailed_errcodes=1');
$bucket = $cluster->openBucket('mybucket');
$doc = $bucket->get('docid');

So the bottom line is that Couchbase throws exception whenever I append query string to the DSN (it does not have to be “detailed_errcodes”).

I’ve tested it with PHP 7.1.6 and 7.2.1 + Couchbase Enterprise 4.5 and 5.

2

I don’t see where you setup authenticator. Does your bucket has password? You should use PasswordAuthenticator for current stable version of the server or ClassicAuthenticator if you are using legacy servers.

If you are using current server, you can use shortcut Cluster#authenticateAs($username, $password) as shortcut for PasswordAuthenticator.

3

My buckets do not have password. Do I have to use an authenticator for buckets without password? The code works just fine without ?detailed_errcodes=1.

4

Couchbase does not allow passwordless access to buckets, could you create a user and configure authenticator?
https://developer.couchbase.com/documentation/server/current/security/security-pw-auth.html

LCB_EINVAL means you incorrectly setup the library, could you show the log on DEBUG or TRACE level?

5

It works for me for the previously existing buckets and version 4.5. For any new buckets, yes…I have to use password. I have version 5 locally that I upgraded from 4.5. Any buckets existed in 4.5 works without password.

DEBUG result

[08-Apr-2018 04:26:22 America/Los_Angeles] [cb,DEBG] (pcbc/cluster L:47) Initialize Cluster. C=0x112a03040 connstr="127.0.0.1:8091?a"
[08-Apr-2018 04:26:22 America/Los_Angeles] [cb,DEBG] (pcbc/pool L:183) Rewrite connection string from "127.0.0.1:8091?a" to "127.0.0.1:///catalog?a"
[08-Apr-2018 04:26:22 America/Los_Angeles] [cb,EROR] (pcbc/pool L:58) Failed to initialize LCB connection: LCB_EINVAL: Invalid input/arguments
[08-Apr-2018 04:26:22 America/Los_Angeles] PHP Fatal error:  Uncaught Couchbase\Exception: LCB_EINVAL: Invalid input/arguments
6

your connection string does not look like right. write it like this:

couchbase://127.0.0.1/catalog

No need to specify port if it is default

7

I asked a question about protocol…a year ago or so if it matters or not. The answer was no as far as I remember.

Any of these works just fine

http://127.0.0.1:8091
127.0.0.1:8091
couchbase://127.0.0.1:8091

If you strace a test code, Couchbase SDK actually tries to choose HTTP or Couchbase based on availability I believe.

Appending protocol does not make a difference in this case. All of them work just fine with or without protocol.

8

they are not equivalent, and libcouchbase treats them differently (and always did). Also your logs show invalid query string, which might be because of incorrect query string. So please fix your connection strings.

9

I DID and tested before replying. I also never said they are equivalent. I wrote that they work regardless of protocol.

All three of them work just fine without query string.
All three of them do not work with query string.

I’m grateful that you are trying to help, but we are getting distracted. As I noted in my previous posts, protocol does not affect this issue. I’ve tested with and without protocol.

I guess my question was not direct enough.

Is “detailed_errcodes” (or any other strings after couchbase address) still supported or is this completely abandoned? If so, can I consider this as another BC or bug?

10

yes, it is supported, so how your issue could be reproduced?

11

I pasted my test code…

12

ok, I ran my test scripts a few more times. My apologies for the incorrect information earlier.

with the older version of SDK:

works: 127.0.0.1:8091?detailed_errcodes=1
works: http://127.0.0.1:8091?detailed_errcodes=1
works: couchbase://127.0.0.1?detailed_errcodes=1

with the latest version of SDK
does not work: 127.0.0.1:8091?detailed_errcodes=1

My apologies for the incorrect reply above. These two work. I had to refresh a few times after testing 127.0.0.1:8091.
works: http://127.0.0.1:8091?detailed_errcodes=1
works: couchbase://127.0.0.1?detailed_errcodes=1

Regardless of http:// or couchbase://, the older version of SDK worked without protocol.

it looks like the solution is to append the protocol all the time now, which is still breaking change (not sure if that’s from SDK or libcouchbase).

Thank you for the follow up.

13

127.0.0.1:8091?detailed_errcodes=1
That could be easily fixed if you insert / after the hostname like this:

127.0.0.1:8091/?detailed_errcodes=1

The following interactive session of PHP shows how different URLs are parsed:

$ php -a
Interactive shell

php > var_dump(parse_url('http://127.0.0.1:8091?detailed_errcodes=1'));
array(4) {
  ["scheme"]=>
  string(4) "http"
  ["host"]=>
  string(9) "127.0.0.1"
  ["port"]=>
  int(8091)
  ["query"]=>
  string(19) "detailed_errcodes=1"
}

php > var_dump(parse_url('127.0.0.1:8091/?detailed_errcodes=1'));
array(4) {
  ["host"]=>
  string(9) "127.0.0.1"
  ["port"]=>
  int(8091)
  ["path"]=>
  string(1) "/"
  ["query"]=>
  string(19) "detailed_errcodes=1"
}

php > var_dump(parse_url('127.0.0.1:8091?detailed_errcodes=1'));
array(3) {
  ["scheme"]=>
  string(9) "127.0.0.1"
  ["path"]=>
  string(4) "8091"
  ["query"]=>
  string(19) "detailed_errcodes=1"
}

You can see, that in last case PHP incorrectly extracts schema and whole string turned into invalid parts.

14

I really don’t have time to go and find what the old SDK was doing, but 2.1.0 SDK used to work just fine without protocol. My point is that this is another breaking change.

Yes, it looks like the current version of the SDK treats the connection string differently.

I was able to fix it by making sure we use couchbase://