couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: Handle the Welcome Request
Date Tue, 15 Apr 2014 19:10:42 GMT

Regardless of whether changing GET / would break current replication it’s still not a smart
move. It breaks compatibility by definition. It’s also unnecessary, a vhost + rewrite setup
can obviously serve a suitable page for / for the vhost.

And if couchdb isn’t using the source and target uuid’s, where available, it should in
a future release.


On 15 Apr 2014, at 19:12, Dale Harvey <> wrote:

> Yup as far as the implementation thats right,
> Saying its useless is wrong though, if you do a file based replication the
> databases should have the same uuid, it does in the pouch implementation at
> least, the entire point is that a host does not map to a database, its data
> does.
> Pouch uses a get on / to fetch the uuid, it will use the host if that
> request fails, that just means < 1.3 couchdb's and ones that plays around
> with / will fallback and more likely to do redundant replications in the
> case of a changed host.
> Theres a related post on the replication mailing list
> which I think having per db uuid's would be beneficial for multiple
> reasons
> On 15 April 2014 18:50, Alexander Shorin <> wrote:
>> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <> wrote:
>>> On Apr 14, 2014, at 11:50 PM, Alexander Shorin <> wrote:
>>>> Not, it wouldn't. The replicator doesn't request source or target UUID
>>>> via API, but takes the value from server which runs the replication.
>>> No, I meant the _remote_ server’s UUID. The only way to get that is to
>> send a "GET /" request.
>>> Anyway, I’m trying to verify this but not seeing it right now. I’m
>> seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem
>> redundant!] but not the GET /. Pretty sure I’ve seen this in the past,
>> though, and it does seem the only way for the replicator to get the UUID,
>> which is used to construct the checkpoint ID (right?)
>> No, there wasn't ever used GET / request in CouchDB replication.
>> Server UUID was introduced in 1.3 release: before it pair (host,port)
>> was used and since that time no changes were made for that process.
>> The remote server UUID usage is a little useless, since replication ID
>> for protocol version 3 between two remote servers is based on next
>> structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
>> Headers}}. If you replace LocalUUID with any remote server's UUID
>> value this would change nothing, but will cost you one additional
>> request, losing portability since pre-1.3 releases has no UUID value
>> and replication startover in case when remote database will be
>> migrated to the another instance with the same URL (some
>> proxy/balancer in front of remote instance is the common case).
>> --
>> ,,,^..^,,,

View raw message