Correct me if I'm wrong, but I believe CouchDB does in fact have a vhosts 
feature.

Mike

On Jun 21, 2010, at 1:28 PM, Noah Slater wrote:

> 
> On 21 Jun 2010, at 18:15, Andrew Melo wrote:
> 
>> On Mon, Jun 21, 2010 at 6:10 PM, Nils Breunese <[email protected]> wrote:
>> 
>>> It might be pretty confusing if the A record changed after the last time
>>> the server was started. I've never seen a daemon allowing you to bind to a
>>> hostname. Also, what happens when your resolver is down? CouchDB can't
>>> start?
>>> 
>>> But yeah, it could be implemented I guess.
>>> 
>> 
>> For the machines I run, I set up different hostnames in /etc/hosts for the
>> external and internal interface, so if I have to move it (for whatever
>> arcane reason), I can make one change and have all the binded addresses
>> change as well. (I use DNS to change the A records so that external clients
>> can find it, but that's a different problem)
> 
> Agreed, I regularly use /etc/hosts to manage internal IP spaces. I could use 
> BIND if I felt like a bit of flagellation. Either way, it's certainly 
> something I can see a use for. If your DNS resolution fails, then CouchDB 
> errors out, like it would if it didn't have permission to open a port.
> 
> However, from:
> 
>       http://httpd.apache.org/docs/2.0/dns-caveats.html
> 
> We have:
> 
>> This page could be summarized with the statement: don't configure Apache in 
>> such a way that it relies on DNS resolution for parsing of the configuration 
>> files. If Apache requires DNS resolution to parse the configuration files 
>> then your server may be subject to reliability problems (ie. it might not 
>> boot), or denial and theft of service attacks (including users able to steal 
>> hits from other users).
> 
> Apache httpd is intended to be deployed in shared environments, however. 
> CouchDB doesn't have a vhost feature, and I can't imagine it providing one. 
> We'd almost certainly just tell users to proxy back from an Apache vhost to a 
> specific database, or what have you. So may be these concerns don't apply.

Reply via email to