Mailing-List: contact couchdb-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jwall@google.com designates
 216.239.33.17 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=message-id:date:from:to:subject:in-reply-to:mime-version:
	content-type:references;
	b=H2X22arnLnYzsvxm5kalVTdmQdSZsunF6MWmMqLsz7+gwu/XDC7fjX8s23o5yXM4T
	FcPIDM8iJ5zGGsSQ0jXnw==
Message-ID: <7c40ded80809031544g37babd5byac6a98d15ebc1825@mail.gmail.com>
Date: Wed, 3 Sep 2008 17:44:23 -0500
From: "Jeremy Wall" <jwall@google.com>
To: couchdb-dev@incubator.apache.org
Subject: Re: URL-decoding reverse proxy breaks remote replication
In-Reply-To: <ED6FC027-05C2-4253-8184-52DDE13E6B04@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1128_9655807.1220481864015"
References: <0D2EE974-228C-4C7E-A4DC-61CF9D9C8A9F@gmail.com>
	 <DC67AC4E-37F7-4EB7-A1F4-1BF93400526C@apache.org>
	 <7c40ded80809031226k19e134c8o56071ca299fe8c89@mail.gmail.com>
	 <ED6FC027-05C2-4253-8184-52DDE13E6B04@gmail.com>

------=_Part_1128_9655807.1220481864015
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Unfortunately the server is only running 2.2.3 and I can't upgrade it so I
guess I'm stuck. :-(

On Wed, Sep 3, 2008 at 3:03 PM, Adam Kocoloski <adam.kocoloski@gmail.com>wrote:

> Hi Jeremy, I think Apache added a "nocanon" keyword in 2.2.7+ that's
> supposed to pass raw URLs onto the backend.  Have you tried that?  Best,
>
> Adam
>
>
> On Sep 3, 2008, at 3:26 PM, Jeremy Wall wrote:
>
>  An Apache reverse proxy also breaks with url encodings. So that's at least
>> one other proxy that does it.
>>
>> On Wed, Sep 3, 2008 at 2:13 PM, Damien Katz <damien@apache.org> wrote:
>>
>>  This is an issue I've been anticipating for a while, which is proxies
>>> messing around with the url encoding and causing problems.
>>>
>>> CouchDB url elements are delimited by slashes, for example "GET
>>> db/doc/fileattachment". But any of the elements "db" "doc" or
>>> "attachment"
>>> could have slashes in them,  if slashes are url encoded (%20 I think).
>>>  So
>>> using the slashes requires that the proxies keep the encoding exactly
>>> intact, instead of normalizing encoded urls to slashes.
>>>
>>> I've discussed this a while ago and was advised that proxies shouldn't
>>> mess
>>> with the URL encodings. So too me, my default position is this to me is a
>>> bug in nginx. However, I can be convinced otherwise, if other proxies or
>>> tools tend to do the same thing.
>>>
>>> -Damien
>>>
>>>
>>> On Sep 3, 2008, at 2:38 PM, Adam Kocoloski wrote:
>>>
>>> Hi, I installed CouchDB behind nginx the other day and noticed that
>>> remote
>>>
>>>> replication didn't work.  The problem seems to be that
>>>>
>>>> a) CouchDB stores the replication history in a local doc with an ID
>>>> formed
>>>> from the URL-encoded paths to the source and target DBs,
>>>>
>>>> b) nginx decodes all %2Fs in the URLs it processes, and
>>>>
>>>> c) couch_httpd chokes on a GET request for the replication history doc
>>>> using the decoded URL delivered by nginx.
>>>>
>>>> My workaround was to encode "/" as "|" in the ID of the replication
>>>> history document.  It seemed simpler than doing extra special-casing in
>>>> couch_httpd to handle decoded "/" characters in replication docIDs, and
>>>> I
>>>> didn't see any way to turn off URL decoding in nginx.  Best,
>>>>
>>>> Adam
>>>>
>>>> --- a/trunk/src/couchdb/couch_rep.erl
>>>> +++ b/trunk/src/couchdb/couch_rep.erl
>>>> @@ -28,6 +28,9 @@ url_encode([H|T]) ->
>>>>      [H|url_encode(T)];
>>>>  H == $_; H == $.; H == $-; H == $: ->
>>>>      [H|url_encode(T)];
>>>> +    % nginx will decode the %2F which makes couch_httpd blow up
>>>> +    H == $/ ->
>>>> +        [$||url_encode(T)];
>>>>  true ->
>>>>      case lists:flatten(io_lib:format("~.16.0B", [H])) of
>>>>      [X, Y] ->
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>

------=_Part_1128_9655807.1220481864015--