incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Weber <>
Subject Re: Handle the Welcome Request
Date Tue, 15 Apr 2014 21:08:08 GMT
Now that is discussion is back on the original track...   :-)

I still can't get it to work.  Vhost + rewrite isn't doing it.

My document "source" has an attachment called "login.html"

    test.localhost = /login/source/
is working. (yes, I made that a local definition for testing)
It is giving me the document called 'source'.

Rewrite is not. Trying all sorts of combos of what this page says:

My doc is this:

   "_id": "_design/_rewrite",
   "_rev": "6-743615f8003e4bd0d62adfb0c9406263",
   "rewrites": [
           "from": "/",
           "to": "login.html"

But all I ever get is the DBDoc.

I have made 6+ revisions already.  I did not paste them all.
I have made a bunch of variations on the name:  "_design/_rewrite"  "_design/rewrite" "_design/source"...

All the log says is: ... [<0.440.0>] - - GET /login/source/ 200

Rather than continue to shoot in the dark...  it's time to ask for help again.

 From: Robert Samuel Newson <>
Cc: Scott Weber <> 
Sent: Tuesday, April 15, 2014 2:10 PM
Subject: Re: Handle the Welcome Request

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).
>> --
>> ,,,^..^,,,
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message