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 17:00:33 GMT
On Thu, Aug 19, 2010 at 22:23, Benoit Chesneau <> wrote:

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

Back around 0.9, there was a huge discussion about "transactional" bulk

The prevailing view was that CouchDB does not show a behavior unless it can
show that behavior in all possible deployments.

I am asking if the same logic applies here.

In the future when every device has CouchDB and every ISP runs it and every
carrier caches it and everything, apps need to work there too. That is why I
am attracted to a simple vhost implementation.

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

Since I wrote the whitelist feature, yes I am aware how I could work around
supporting this.

I have operational concerns. However I am simply asking that the community
think very hard about what this means before permanently committing to it.

Specifically, the fact is CouchDB is a fantastic platform with very, very
few good applications. CouchDB is years ahead of the popular couchapps with
respect to polish and features.

My point is, are we bending CouchDB in order to cover for the fact that
there is no good App Admin tool out there?

Maybe the answer is no. Okay, fine, as long as the decision is deliberated
and understood by everybody, cool! I do agree about two things:

 1. It is difficult for beginners to develop on localhost:5984 and then push
to couch.domain.tld. vhost is managed separate from the ddoc and even the
DB, so it does not replicate. It totally sucks.
 2. It is hard to manage vhosts. You have cURL and you have Futon, which did
not even work correctly in 1.0.0.

It would bother me if I do not know which "Host" header to reply to without
inspecting all database and ddocs.

My preference is dumb vhosts and a smart rewriter. For example, if the
rewrite rule could see the req object and Host header, it could redirect to
the correct db, ddoc, and path.

Jason Smith
Couchio Hosting

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