CouchDB复制在代理后面无法正常工作
[英]CouchDB replication is not working properly behind a proxy
问题描述
Note: Made some updates based on new information. 注意：根据新信息进行了一些更新。 Old ideas have been added as comments below. 旧观点已添加为以下评论。 Note: Made some updates (again) based on new information. 注意：根据新信息进行一些更新（再次）。 Old ideas have been added as comments below (again). 旧的想法已被添加为下面的评论（再次）。
We are running two instances of CouchDB on separate computers behind Apache reverse proxies. 我们在Apache反向代理后面的不同计算机上运行两个CouchDB实例。 When attempting to replicate between the two instances: 尝试在两个实例之间复制时：
curl -X POST http://user:pass@localhost/couchdb/_replicate -d '{ "source": "db1", "target": "http://user:pass@10.1.100.59/couchdb/db1" }' --header "Content-Type: application/json"
(we started using curl to debug the problem) （我们开始使用curl来调试问题）
we receive an error similar to: 我们收到类似于的错误：
{"error":"case_clause","reason":"{error,\n {{bad_return_value,\n {invalid_json,\n <<\"<!DOCTYPE HTML PUBLIC \\\"-//IETF//DTD HTML 2.0//EN\\\">\\n<html><head>\\n<title>404 Not Found</title>\\n</head><body>\\n<h1>Not Found</h1>\\n<p>The requested URL /couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20 was not found on this server.</p>\\n<hr>\\n<address>Apache/2.2.3 (Red Hat) Server at 10.1.100.59 Port 80</address>\\n</body></html>\\n\">>}},\n {child,undefined,\"01e935dcd2193b87af34c9b449ae2e20\",\n {gen_server,start_link,\n [couch_rep,\n [\"01e935dcd2193b87af34c9b449ae2e20\",\n {[{<<\"source\">>,<<\"db1\">>},\n {<<\"target\">>,\n <<\"http://user:pass@10.1.100.59/couchdb/db1\">>}]},\n {user_ctx,<<\"user\">>,\n [<<\"_admin\">>],\n <<\"{couch_httpd_auth, default_authentication_handler}\">>}],\n []]},\n temporary,1,worker,\n [couch_rep]}}}"}
So after further research it appears that apache returns this error without attempting to access CouchDB (according to the log files). 因此，经过进一步的研究，似乎apache在不尝试访问CouchDB的情况下返回此错误（根据日志文件）。 To be clear when fed the following URL 在提供以下URL时要清楚
/couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20
Apache passes the request to CouchDB and returns CouchDB's 404 error. Apache将请求传递给CouchDB并返回CouchDB的404错误。 On the other hand when replication occurs the URL actually being passed is 另一方面，当发生复制时，实际传递的URL是
/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20
which apache determines is a missing document and returns its own 404 error for without ever passing the request to CouchDB. 哪个apache确定是一个丢失的文档，并返回自己的404错误， 而没有将请求传递给CouchDB。 This at least gives me some new leads but I could still use help if anyone has an answer offhand. 这至少给了我一些新的线索，但如果有人有一个答案，我仍然可以使用帮助。
4 个解决方案
解决方案1
2 2011-03-09 04:31:24
The source CouchDB (localhost) is telling you that the remote URL was invalid. 源CouchDB（localhost）告诉您远程URL无效。 Instead of a CouchDB response, the source is receiving the Apache httpd proxy's file-not-found response. 源代码不是CouchDB响应，而是接收Apache httpd代理的文件未找到响应。
Unfortunately, you may have some reverse-proxy troubleshooting to do. 不幸的是，您可能需要进行一些反向代理故障排除。 My first guess is the Host header the source is sending to the target. 我的第一个猜测是源发送到目标的Host头。 Perhaps it's different from when you connect directly from a third location? 也许它与您从第三个位置直接连接时有所不同？
Finally, I think you probably know this, but the path 最后，我想你可能知道这一点，但路径
/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20
Is not a standard CouchDB path. 不是标准的CouchDB路径。 By the time CouchDB sees a request, it should have the /couchdb stripped, so the query is for a document called _local%2f... in the database called db1 . 当CouchDB看到请求时，它应该删除/couchdb ，因此查询是针对名为db1的数据库中名为_local%2f...的文档。
Incidentally, it is very important not to let the proxy modify the paths before they hit couch. 顺便说一句， 非常重要的是不要让代理在它们到达沙发之前修改路径。 In particular, if you send %2f then CouchDB had better receive %2f and if you send / then CouchDB had better receive / . 特别是，如果你发送%2f那么CouchDB最好收到%2f ，如果你发送/那么CouchDB最好收到/ 。
解决方案2
1 2011-03-08 21:29:23
From official documentation... 从官方文件......
Note that HTTPS proxies are in theory supported but do not work in 1.0.1. 请注意，理论上支持HTTPS代理，但在1.0.1中不起作用。 This is because 1.0.1 ships with ibrowse version 1.5.5. 这是因为1.0.1附带ibrowse版本1.5.5。 The CouchDB version in trunk (from where 1.1 will be based) ships with ibrowse version 1.6.2. trunk中的CouchDB版本（1.1将基于哪个版本）附带ibrowse版本1.6.2。 This later ibrowse contains fixes for HTTPS proxies. 后来的ibrowse包含HTTPS代理的修复程序。
Can you see which version of ibrowse is involved? 你能看到涉及哪个版本的ibrowse吗？ Maybe update that ver? 也许更新那个版本？
解决方案3
1 2011-03-08 21:37:11
Another thought I have is with regard to the SSL certs. 我的另一个想法是关于SSL证书。 If you don't have any, and I know you don't :), then technically you're doing SSL wrong. 如果你没有，我知道你没有:)，那么从技术上讲你做错了SSL。 In java we know there are ways around this, but maybe try putting in proper certs since all SSL stuff basically involves certs. 在java中，我们知道有很多方法可以解决这个问题，但是可能会尝试使用适当的证书，因为所有SSL内容基本上都涉及证书。
解决方案4
1 2011-03-08 21:41:52
And for my last contribution (today) I would say have you looked through this document which seems highly relevant? 对于我上一次的贡献（今天），我想说你看过这个看似高度相关的文件吗？
http://wiki.apache.org/couchdb/Apache_As_a_Reverse_Proxy http://wiki.apache.org/couchdb/Apache_As_a_Reverse_Proxy
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.