couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
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 <jhs@couch.io> wrote:
> On Thu, Aug 19, 2010 at 21:27, Benoit Chesneau <bchesneau@gmail.com> 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 :

[httpd]
redirect_vhost_handler = {couchone_httpd, vhost_handler}

then

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
    end,

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

    Headers = mochiweb_headers:enter("x-couchdb-vhost-path", Path,
        MochiReq:get(headers)),

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

    MochiReq1.


done.


>
> 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.

Mime
View raw message