[NOTE]: # ( ^^ Provide a general summary of the issue in the title above. ^^ )
…
## Description
I am attempting to schedule replication between two instances which only have IPv6 connectivity between them. The failure in the logs suggests that this parser cannot accept IPv6 addresses.
## Steps to Reproduce
- `curl -X PUT 'http://[fd19:ca4f:1891:0:c77d:21c3:80b1:47d5]:5984/a'`
- `curl -X PUT 'http://[fd19:ca4f:1891:0:c77d:21c3:80b1:47d5]:5984/a/a' -d '{}'`
- `curl -X PUT 'http://[fd19:ca4f:1891:0:5d59:4c52:1d67:4f85]:5984/b'`
### Replicate Endpoint
- `curl -X POST -H 'Content-Type: application/json' 'http://[fd19:ca4f:1891:0:5d59:4c52:1d67:4f85]:5984/_replicate' -d '{"source":"http://[fd19:ca4f:1891:0:c77d:21c3:80b1:47d5]:5984/a","target":"http://[fd19:ca4f:1891:0:5d59:4c52:1d67:4f85]:5984/b"}'`
- `{"error":"nxdomain","reason":"could not resolve http://[fd19:ca4f:1891:0:c77d:21c3:80b1:47d5]:5984/a/"}`
### Fauxton
This one is trickier to replicate via curl IMO, so instead I've included an image of the configuration and then the output logs.
Logs:
- `[error] 2022-01-09T23:52:44.193423Z couchdb@127.0.0.1 <0.9118.0> -------- couch_replicator_httpc: auth plugin initialization failed "http://[fd19:ca4f:1891:0:c77d:21c3:80b1:47d5]:5984/a/" {session_request_failed,"http://fd19:ca4f:1891:0:c77d:21c3:80b1:47d5/_session","admin",{url_parsing_failed,{error,invalid_uri}}}`
- `[error] 2022-01-09T23:52:44.193636Z couchdb@127.0.0.1 <0.9118.0> -------- throw:{replication_auth_error,{session_request_failed,"http://fd19:ca4f:1891:0:c77d:21c3:80b1:47d5/_session","admin",{url_parsing_failed,{error,invalid_uri}}}}: Replication 0d172815abcfddb7ae70200408d7f6b8 failed to start "http://[fd19:ca4f:1891:0:c77d:21c3:80b1:47d5]:5984/a/" -> "http://[fd19:ca4f:1891:0:5d59:4c52:1d67:4f85]:5984/b/" doc <<"shards/00000000-7fffffff/_replicator.1641770003">>:<<"52b362d49d9b3f9b57b03fed76000352">> stack:[{couch_replicator_httpc,setup,1,[{file,"src/couch_replicator_httpc.erl"},{line,59}]},{couch_replicator_api_wrap,db_open,3,[{file,"src/couch_replicator_api_wrap.erl"},{line,74}]}]`
## Expected Behaviour
- Replication to occur as with IPv4.
- More specifically, the URLs are in (I believe) the correct format for a directly specified IPv6 address, yet it seems for the `_replicate` endpoint these are parsed as domains, and the `_replicator` databases treats them as invalid addresses.
## Your Environment
CouchdbTest1 (fd19:ca4f:1891:0:c77d:21c3:80b1:47d5/64):
`{"couchdb":"Welcome","version":"3.2.1","git_sha":"244d428af","uuid":"7e9872dd6737bc29302be23caf5294c1","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}`
CouchdbTest2 (fd19:ca4f:1891:0:5d59:4c52:1d67:4f85/64):
`{"couchdb":"Welcome","version":"3.2.1","git_sha":"244d428af","uuid":"b6a91ada70259942daf27bc5fbad8f4a","features":["access-ready","partitioned","pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}`
* CouchDB version used:
* curl 7.74.0
* Debian 11 Bullseye.
## Additional Context
I found https://issues.apache.org/jira/browse/COUCHDB-665 when searching, which suggests that this bug may be a regression. I used similar commands to them, with the difference being that I created two separate virtual machines for testing, rather than using a single host.
I haven't replicated this in this bug report, but I also tried on some other systems allocating a DNS name with a AAAA record to the same IPv6 addresses. This also did not immediately solve the problem, but I have left it out of this bug report as it might be a confounding variable.