couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Vhosting Requirements (was: Re: [jira] Commented: (COUCHDB-230) Add Support for Rewritable URL)
Date Thu, 19 Aug 2010 15:23:32 GMT
To answer in a more generic way. As a "sys admin" or "operatives", you
are already habit to vhosts or Locations with http servers. This is
the same system here. Nothing new, just a syntax different.

I think also there is 2 views of couchdb in oposition here. One is
about managing couchdb in multi mass hosting other is to see couchdb
as a standalone db that could be used on any device.

Now answering to other questions:

On Thu, Aug 19, 2010 at 4:59 PM, Jason Smith <> wrote:
> On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau <> wrote:
>> Could you explain me how it's impossible compared to previous
>> behaviour ? It doesn't change anything technically. Please post all
>> your concern and a way to reproduce , I will have a look on it. Though
>> here hosting > 50 couch - trunk behingd couchdbproxy works. tested
>> yesterday.
> ## The top priority question:
> How can proxies managed by the sysadmin or network admin know what to do?
> Now, vhost is explicit. Anybody with permission can query /_config/vhosts
> for all couches.

That was the case since Jan added this features. Nothing changed and I
think that couchone is running.

> With wildcards, e.g. "*/blog", it is impossible to know all domains which
> the web server handles. When a query for  fooapp.foodb.mydomain.tld arrives,
> which couch should handle it?

This feature isn't yet implemented. It only works for domain names.
You don't need to use a wildcard. If you're worried about your users
and the fact they could use this feature, I am thinking this is just
an operative concern. If you don't want that your user set vhosts like
this then you will have to think to a way to do this. I'm not sure
that couchdb should concern about it, especially since you can
whitelist _config. You could also create your own _config handler that
filter entries .

Other simple way. Use your own vhost rewriter :

in ini :

redirect_vhost_handler = {couchone_httpd, vhost_handler}


vhost_handler(MochiReq, VhostTarget) ->
    Path =  MochiReq:get(raw_path),
    {"/" ++ TargetPath, _, _} = mochiweb_util:urlsplit_path(VhostTarget),
    {Firstpart, _, _} = mochiweb_util:partition(TargetPath, "/"),

    %% get target path
    Target = case DbName of
        <<'_utils" ->
        _ ->
                AppPath = VhostTarget ++ Path

    ?LOG_DEBUG("Vhost Target: '~p'~n", [Target]),

    Headers = mochiweb_headers:enter("x-couchdb-vhost-path", Path,

    % build a new mochiweb request
    MochiReq1 = mochiweb_request:new(MochiReq:get(socket),
    % cleanup, It force mochiweb to reparse raw uri.



> CouchDB adoption is growing. The network, system, and programming
> responsibilities are becoming different people. It needs to allow everybody
> to do their job.
> ## The medium priority question
> I have not decided how I feel about "smart" vhosts.
> Is it really wrong with 1,000 vhost entries? For sure, *something* must be
> smart to allow managing 1,000 couchapps, however I am not sure if the vhost
> is the best answer.
> One possibility is CouchApp. Currently, CouchApp has no idea about rewrites
> and vhosts, `rewrites.json` is plain old data. Maybe CouchApp is the best
> place to set vhosts and rewrites. The .couchapprc is 3 nested JSON objects!
> Is a good place to say, "when you push to this URL, please also configure
> vhosts so fooapp.foodb.mydomain.tld will go to _rewrite"?

I don't think it could work. You don't want to read all dbs to know if
an host was set.

> Another possibility is a dedicated tool to manage CouchDB, perhaps within
> Futon, or perhaps standalone. Besides vhosts, there are many things that are
> becoming difficult to manage.
>  * Database _security object
>  * _config
>  * _users (mostly changing passwords but also role management is quite
> basic)
> When deploying a CouchApp, these must be synchronized between development
> and production (_users could replicate). In other words, vhost is not the
> only problem when you have 1,000 CouchApps. I think all these problems are
> related: there is no "app management console" yet.

I know at least one but not public yet.

> ## The low priority question:
> Finally, as a sysadmin, wonder about the $var -> $var syntax. I do not enjoy
> learning another domain-specific language just to get my job done. What does
> '$' mean? Maybe it is like shell variables? But shell variables do not use
> '$ when assigning, only when expanding. What other differences are there?
> What about underscore? Does $foo_bar match anything, or only
> anything+"_bar"? Ultimately, I must look in the documentation to make sure.

> There is already a syntax for this included in Erlang: regular expressions.
> (.*).(.*).mydomain.tld -> /$2/_design/$1/_rewrite
> Finally, I am happy to get new changes, just trying to figure out what is
> best for everybody.

Regexps are complicated, Regexps are slow (especially in erlang). Here
we only do pattern matching. There is no complexity. Host is splitted
between dots ('.') . if between dots you have a $ it is considered as
a variable. wildcard are here as a convenience too.  we could likely
use a list but I think users prefers to just set a variable name
rather having to split themselves all the domain names. If so
considered it's fine, we could just use list then.

View raw message