Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.213.52 as permitted sender)
Date: Sat, 17 Sep 2011 21:07:57 -0400
From: Adam Kocoloski <adam.kocoloski@gmail.com>
To: user@couchdb.apache.org
Message-ID: <CCA3595835DB46EFAEFD4B085D7C59D3@gmail.com>
In-Reply-To: 
 <CAHZBNKbjERApkMVk3RkLs2iFKZLtcnt91ao48Cp5prUsWm3MRw@mail.gmail.com>
References: <4E73C24C.2080005@gmail.com>
 <CAHZBNKYjmSJVeXJOzEhjgc74J4-7Lj_Px6+vnfPZrJ1mTd44eQ@mail.gmail.com>
 <CAHZBNKbjERApkMVk3RkLs2iFKZLtcnt91ao48Cp5prUsWm3MRw@mail.gmail.com>
Subject: Re: "%2F" problems
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Kevin, there are a few possibilities, one of which is that the replica=
tor gets confused about the expected length of the response body. My reco=
llection is that the replicator in 1.0.x and 1.1.x ignores the actual val=
ue of the content-length header when pulling an attachment and instead ex=
pects to read the number of bytes specified in the =5Fattachments metadat=
a in the document (I'm not sure about the behavior of the new replicator =
in 1.2 in this respect). Throw attachment compression into the mix and th=
ings can get tricky. =46or example, it might be the case that the =5Fatta=
chments metadata contains the identity length of the attachment but that =
the attachment is ultimately served in compressed form during the replica=
tion.

As far as workarounds go, can you initiate the replication from the sourc=
e server and specify the local database name as the source=3F You'll use =
a rather different code path.

Adam

On Saturday, September 17, 2011 at 6:30 PM, Dave Cottlehuber wrote: =20
> Sorry Kevin, my apologies, only read =C2=BD of that email - clearly quo=
ting
> alone isn't enough to explain this.
> =20
> What version(s) or buidls of CouchDB are involved=3F
> Also, are you able to post some of the logs online in debug mode=3F
> =20
> Thanks
> Dave
> =20
> On 18 September 2011 10:17, Dave Cottlehuber <dave=40muse.net.nz (mailt=
o:dave=40muse.net.nz)> wrote:
> > On 17 September 2011 09:40, Kevin R. Coombes <kevin.r.coombes=40gmail=
.com (mailto:kevin.r.coombes=40gmail.com)> wrote:
> > > I am trying to replicate a couch database from one Windows machine =
to
> > > another. Replication halts with an error when it gets to an attachm=
ent of
> > > the design document. The error message in the (local) log file just=
 before
> > > the stack dump says
> > > =20
> > > =5B=46ri, 16 Sep 2011 21:22:57 GMT=5D =5Berror=5D =5B<0.813.0>=5D s=
treaming att. ended but
> > > more data requested =7B1316,208177,498001=7D
> > > =5B=46ri, 16 Sep 2011 21:22:57 GMT=5D =5Binfo=5D =5B<0.813.0>=5D re=
quest for
> > > =22=5Fdesign%2=46basic/docs.html=22 timed out, retrying in 0.5 seco=
nds
> > > =20
> > > The replication was started by sending a POST to the local machine;=
 I am
> > > using pull replication from a remote source to the local target. Ad=
mins are
> > > set up on the local machine, and I provided the admin credentials b=
oth as
> > > part of the URL starting the replication and as part of the target =
URL.
> > > =20
> > > When I use =22curl=22 from the command line on the local machine to=
 request a
> > > file from the remote machine, the command
> > > curl =5BREMOTEDB=5D/=5Fdesign%2=46basic/docs.html
> > > returns nothing, while the command
> > > curl =5BREMOTEDB=5D/=5Fdesign/basic/docs.html
> > > returns the correct file.
> > > =20
> > > Clearly, there is something about the encoding of a forward slash a=
s a =22%2=46=22
> > > that is confusing both me and at least one of the couch instances i=
nvolved
> > > in this attempt at replication.
> > > =20
> > > Can someone tell me =5B1=5D what is the underlying source of the pr=
oblem=3F and
> > > =5B2=5D how do I persuade couch to just replicate the design docume=
nts properly=3F
> > > =20
> > > Thanks,
> > > Kevin
> > =20
> > Hi Kevin,
> > =20
> > I assume you're driving replication via curl, in a cmd.exe shell, and=

> > that things work via futon.
> > =20
> > =5B1=5D is likely quoting which is not obvious on windows
> > http://wiki.apache.org/couchdb/Quirks=5Fon=5FWindows has some example=
s on
> > fixing this. Using curl -v should show you what the actual text sent
> > through to CouchDB is.
> > =20
> > =5B2=5D depending on whether you're running in admin party or not, yo=
u may
> > need to include username:password=40couch for ddocs to replicate.
> > =20
> > A+
> > Dave