couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 20:57:00 GMT
On Fri, Aug 20, 2010 at 03:31, J Chris Anderson <> wrote:

> My point is that if you have an app that requires a vhost to work, then you
> have to do some machine level configuration to get more than one (or maybe
> 2) vhosts, from a standard issue Mac or Windows box. You can't ask grandma
> to do that.

I'm not clear on "requires." You can still go to /db/_design/app/_rewrite/
without vhost rules.

> If the vhost directive allowed matching on parts of the path, then you
> could have */foobar = /foo/_design/bar/_rewrite and then the user could just
> visit localhost:5984/foobar and have it work.

That's a cool feature. But it has ramifications for reverse proxies. If the
proxy gets a request for it will not easily know where to
send it because every couch on the back end has the same vhost setting:
*/foobar. In other words, you could no longer use the union of all
_config/vhosts as a registry for all domains to serve. I brought up
transactional _bulk_inserts because the conclusion was, if it works in any
situation, it must work in all situations. But yes, the situations are

Since the path queried is in the HTTP request, reverse proxies have no
problem. Unless you are rewriting. A rewriter can change that path, which
could trigger a different vhost setting, or could it? And if so, is there
impact on secure_rewrites?

vhost: */sofa = /blog/_design/sofa/_rewrite
rewrite: {from: "pages/*", to:"../../../pages/*"}
vhost: */pages = /pages/_design/pages/_rewrite

This is contrived, I'm just working this out. But is the expectation here
that /sofa/pages/foo would return the "foo" wiki page or 404?

Jason Smith
Couchio Hosting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message