On Jun 12, 2009, at 6:03 AM, Benoit Chesneau wrote:

Hi all,

I'm trying to replicate a source database behind a nginx proxy. All
docs seem replicated in target db but replication never ending.

Configuration of nginx is :
server {
       listen 88.191.73.9:80;
       server_name nymphormation.org www.nymphormation.org;

       location / {
               proxy_pass http://127.0.0.1:5985;
               proxy_redirect default;
               proxy_set_header X-Orig-Host '$host:$server_port';

               if ($request_uri ~* "^/$") {
                       rewrite ^/$
http://nymphormation.org/n/_design/nymphormation/_list/links/news?limit=11&descending=true
permanent;
               }
       }

       location ~ ^/robots.txt {
           root /home/nymphormation/www;
       }

  }

To reproduce I just do a simple replication of
http://nymphormation.org/n to a local db. Could the problem appear due
to rewriting of / ?



- benoƮt

Hi Benoit, the error occurs when the replicator tries to POST to _ensure_full_commit on nymphormation.org. This POST has no body and no Content-Length header, which drives nginx batty. The response that comes back from your server is

<html>
<head><title>411 Length Required</title></head>
<body bgcolor="white">
<center><h1>411 Length Required</h1></center>
<hr><center>nginx/0.7.41</center>
</body>
</html>

and the replicator chokes on that because it's expecting JSON. I think nginx is being overly strict here; HTTP/1.1 does not require a Content-Length header, especially for empty request bodies.

In my opinion this is a bug in nginx, not Couch. It's particularly annoying when working in Erlang because the inets HTTP client actually _strips off_ the Content-Length header if no body is present. I'm a bit confused, though, because the nginx changelog (http://nginx.net/CHANGES ) indicates that as of 0.7.25 POSTs do not require a Content-Length.

There are a few things we could do in Couch, including a) manually adding the Content-Length : 0 header to the request and b) not letting ourselves get stuck in an infinite receive when ensure_full_commit fails like this. The latter we should definitely do; I'm ambivalent about the former. Best,

Adam

Reply via email to