incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin R. Coombes" <kevin.r.coom...@gmail.com>
Subject Re: problem with replication through proxy
Date Fri, 17 Jun 2011 14:40:22 GMT
Thanks for your help so far. We are still struggling with this problem.

Apache is not inserting its own error.  Replications succeeds when we 
contact the couch server directly from inside the firewall. Replication 
fails when we try the same thing through the external proxy.  (It fails 
whether we use the JSON from my original email or the version that uses 
a "proxy" setting as described on the wiki.) The error message continues 
to be a 404 not found on the call to try to get the checkpoint.

To verify that the response is the same from the two sources, I wrote a 
perl script to make the checkpoint calls directly and store the result 
to a file.  Here is that file (edited only to remove internal server 
names and IP addresses):

-------
Request:
GET http://[PROXY]/[DB]/_local/9b91176762c7e085feed3a4954a676a2
User-Agent: KRC/0.1 libwww-perl/5.834
-------
Status:
404 Object Not Found
-------
Response:
HTTP/1.1 404 Object Not Found
Cache-Control: must-revalidate
Connection: close
Date: Fri, 17 Jun 2011 14:27:36 GMT
Server: CouchDB/1.0.1 (Erlang OTP/R12B)
Content-Length: 41
Content-Type: text/plain;charset=utf-8
Client-Date: Fri, 17 Jun 2011 14:27:36 GMT
Client-Peer: *****
Client-Response-Num: 1

{"error":"not_found","reason":"missing"}
-------------------------------------------------
Request:
GET http://[COUCH]/[DB]/_local/9b91176762c7e085feed3a4954a676a2
User-Agent: KRC/0.1 libwww-perl/5.834
-------
Status:
404 Object Not Found
-------
Response:
HTTP/1.1 404 Object Not Found
Cache-Control: must-revalidate
Connection: close
Date: Fri, 17 Jun 2011 14:27:36 GMT
Server: CouchDB/1.0.1 (Erlang OTP/R12B)
Content-Length: 41
Content-Type: text/plain;charset=utf-8
Client-Date: Fri, 17 Jun 2011 14:27:36 GMT
Client-Peer: *****
Client-Response-Num: 1

{"error":"not_found","reason":"missing"}
-------

I also note that both servers send the response back with a Content-Type 
of "text/plain" (even though it seems to me that "application/json" 
might be better...), so that cannot be the source of the problem.

Any other suggestions?
     Kevin

On 6/8/2011 3:46 PM, Robert Newson wrote:
> The replicator is looking for a checkpoint. It's perfectly ok if it
> doesn't find one, though.
>
> I suspect Apache is returning its own 404 message (and response body)
> instead of the one that couchdb sends, and that the replicator is
> expecting. Disable the error page handling and have another try.
>
> B.
>
> On 8 June 2011 21:42, Kevin R. Coombes<kevin.r.coombes@gmail.com>  wrote:
>> Hi,
>>
>> We have a setup with CouchDB running behind an Apache proxy, and are having
>> trouble replicating from the proxy to an outside server.  Basically, you can
>> imagine the following setup:
>>
>> Proxy Server:  http://public.proxy.wherever.com
>>     which forwards GET requests (but not PUT, POST, or DELETE) to
>> CouchDB server:  http://internal.couch.wherever.com:5984
>>     and we want to replicate this database to
>> New CouchDB Server: http://somewhere.else.com:5984
>>
>> We started by creating a new empty database ('newdb') on the new server; it
>> contains absolutely no documents.  We then POST a replicaton request to the
>> new server in the form
>>
>> curl -X POST http://somewhere.else.com:5984/_replicate -d
>> '{"source":"http://public.proxy.wherever.com/ourdb",
>> "target":"http://somewhere.else.com:5984/newdb"}'
>>
>> The error message we get has the form
>>     The requested URL
>>         /ourdb/_local/8262b7d6670639f25400d5940bbe4094
>>     was not found on this server.
>>
>> We cannot figure out what it is looking for (since it does not exist on the
>> server...)  And so we cannot tell if this is a problem with the
>> configuration of the proxy server or if it is something about our particular
>> database.  As far as we can tell, none of the documents in the original
>> couch database has an _id that looks anything like this.  (We assigned all
>> of the _id's manually, since there is a good semantic reason to assign
>> meaningful unique _id's in our application.)
>>
>> Can anyone point us in the right direction to resolve this problem?
>>
>> Thanks,
>>     Kevin
>>
>>
>>

Mime
View raw message