Our replicator doesn’t handle it because it expects CouchDB to return the requested design document (since it exists). Jens says "Yes, Sync Gateway doesn't support design documents so it'll return a 404 for those URLs. " which seems to be the route of it.
So, it’s a basic compatibility thing, the question is what to do about it.
Still pondering that.
B.
On 30 Jan 2014, at 13:19, Jan Lehnardt <j...@apache.org> wrote:
> I commented on the issue:
>
> It looks like we are not handling a 404 in the function below, especially
> thefun(200, Headers, StreamDataFun) -> bit (that’s like 171 in
> couch_replicator_api_wrap).
>
> I’m not too familiar with that code, maybe one of Adam, Bob, Filipe, Benoit
> could have a look?
>
> cc dev@
>
> open_doc_revs(#httpdb{} = HttpDb, Id, Revs, Options, Fun, Acc) ->
> Path = encode_doc_id(Id),
> QArgs = options_to_query_args(
> HttpDb, Path, [revs, {open_revs, Revs} | Options]),
> Self = self(),
> Streamer = spawn_link(fun() ->
> send_req(
> HttpDb,
> [{path, Path}, {qs, QArgs},
> {ibrowse_options, [{stream_to, {self(), once}}]},
> {headers, [{"Accept", "multipart/mixed"}]}],
> fun(200, Headers, StreamDataFun) ->
> remote_open_doc_revs_streamer_start(Self),
> {<<"--">>, _, _} = couch_httpd:parse_multipart_request(
> get_value("Content-Type", Headers),
> StreamDataFun,
> fun mp_parse_mixed/1)
> end),
> unlink(Self)
> end),
> receive
> {started_open_doc_revs, Ref} ->
> receive_docs_loop(Streamer, Fun, Id, Revs, Ref, Acc)
> end;
>
> On 29 Jan 2014, at 16:35 , Jens Alfke <j...@couchbase.com> wrote:
>
>> A developer has reported a CouchDB 1.3 exception/crash replicating with the
>> Couchbase Sync Gateway. They've attached the Erlang crash report, but those
>> are about as readable to me as ancient Aramaic, or the logos* of black-metal
>> bands :(
>>
>>
>> https://github.com/couchbase/sync_gateway/issues/248#issuecomment-33523814
>>
>> Could someone who knows CouchDB take a look and give me a clue about what it
>> might be taking exception [sic] to? In my experience, there are some areas
>> where it gets very picky about parsing incoming data, for example the number
>> of newlines at the end of a multipart body. If I had some idea what type of
>> data it was reading when it barfed, that would help me figure this out...
>>
>> Thanks!
>>
>> —Jens
>>
>> * viz.:
>> http://www.rottentomatoes.com/quiz/the-most-unreadable-metal-band-logos/
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
