Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of kevin.r.coombes@gmail.com
 designates 209.85.160.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:cc
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=fDB9k8NmWVyLxpWY9BDBi42vtxFez37OpFxdNix74iVcAzwKtOTccfLIDH0mwM1Rmw
         9cHv7ppUTbPMPUZDhuwnLNIt+0Gs3jna1htqoUsH5EwvZ/ZyiQATQn/mHgGGoRHCmtk+
         fydWWODOwkv88CMCjkZqwG/PG0kiWWJMGhIHk=
Message-ID: <4CC8AB7A.7040307@gmail.com>
Date: Wed, 27 Oct 2010 17:45:14 -0500
From: "Kevin R. Coombes" <kevin.r.coombes@gmail.com>
Organization: UT M.D. Anderson Cancer Center
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: user@couchdb.apache.org
CC: Keith Gable <ziggythehamster@gmail.com>
Subject: Re: Proxy missing path component
References: <4CC82A6C.4000906@gmail.com>
 <254B0824-726A-4854-8706-B47184819B95@gmail.com>
In-Reply-To: <254B0824-726A-4854-8706-B47184819B95@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  The Couch permissions probably would be easier.  But that's not my 
call.  The administrators have been running an Apache proxy for all 
kinds of applications for a long time, so they are more comfortable 
continuing to do things that way.

The difficulty with changing the javascript (either as part of my 
application or as part of couch.js) is that we'd like things to work 
both externally (where the administrators want "couch" as a path 
component) and internally (where "couch" is not part of the path 
component).  I guess the application has to figure out if the call is 
coming from the proxy server or directly from the couchdb server so it 
knows whether to insert the extra component.

Does anyone have an example that illustrates (using javascript and 
couch.js) how to figure out which machine originated the call?

     Kevin

On 10/27/2010 9:20 AM, Keith Gable wrote:
> I can't say for Couch, but Apache doesn't change the request bodies 
> when proxying. So if you're proxying an application which doesn't know 
> how to link to things and include the proxy prefix (/couch or 
> whatever), it won't work right. When I proxy web applications, I 
> always end up having to use something like mod_proxy_html to rewrite 
> content in the page. Obviously this won't work for you, so you might 
> have to change the internal JavaScript library to take your prefix 
> into account.
>
> Couch has permissions though I thought. Wouldn't that route be easier?
>
>
>
> On Oct 27, 2010, at 8:34 AM, "Kevin R. Coombes" 
> <kevin.r.coombes@gmail.com> wrote:
>
>> Hi,
>>
>> For security reasons, our administrators want to put couchdb behind 
>> an Apache proxy.  The setup right now basically provides an 
>> externally visible URL of the form
>>    http://proxymachine/couch/myapp
>> which maps to the internal URL
>>    http://couchmachine/myapp
>>
>> Part of the security point is that the proxy only allows GET 
>> requests, while people behind the firewall can send PUT, POST, or 
>> DELETE to the internal machine.  The extra "couch" path component was 
>> inserted on the proxy because it also works as a server for a variety 
>> of different applications with different stuff going on behind the 
>> firewall.
>>
>> The problem, of course, is that the current configuration fails.  My 
>> application relies on the "couch.js" script via a call like
>>    db = CouchDB("myapp")
>> which results in internal references that look like
>>    /myapp/_design/basic/_view/whatever
>> These end up returning a "404 Not Found" error because the proxy 
>> machine tries to access
>>    http://proxymachine/myapp/_design/basic/_view/whatever
>> Since the "couch" path component is missing, the proxy server does 
>> not rewrite the call, and so the request fails.
>>
>> Is there a way to fix this so that the same javascript will run on 
>> both the proxy server and the internal server?
>>
>> Thanks for any advice,
>>    Kevin