Nginx - Google Summer of Code ideas

mike mike503 at gmail.com
Sat Mar 14 20:02:59 MSK 2009


I'd like to say first - during brainstorming there are no bad ideas :)

On Sat, Mar 14, 2009 at 8:00 AM, Manlio Perillo
<manlio_perillo at libero.it> wrote:

> Its because DAV is not simple to implement.

But nginx already does DAV. I use it for mogilefs without a problem.

What needs to be determined is what is missing to make this happen.
Obviously there are some limitations, but I am sure it can be done.

>>> This does not need to be done with Nginx.
>>> Just use a pre existing healthchecking software with each of the upstream
>>> servers.
>>
>> and what, have an /etc/nginx/upstreams.conf file that i manually
>> update and kill -HUP nginx or whatever appropriate signal to reload
>> every time i notice an upstream going up or down?
>>
>
> Right.

That just seems .... messy. Although if the avahi/zeroconf idea gets
mixed in this might become a moot point as I understand it it would be
discovering and adding/removing automagically.

> If this requires some internal rewrite of Nginx, then I'm not sure it is a
> good idea.

That's why it's thrown out there as an idea.

I'm sure it can be done with a third party module. After all it's just
issuing an HTTP request to an upstream and getting back a response,
and then removing it from the pool.

upstream backend  {
  server backend1.example.com weight=5 check=tcp;
  server backend2.example.com:8080 check=response
url=http://foo.com/health.php expect="hello world";
  server unix:/tmp/backend3;
}

etc?

check=tcp is simple, check=response would expect a plaintext response back.

Or, those attributes could be cleaned up or put into it's own type of block:

response foo {
   url http://foo.com/health.php
   expect "hello world";
}

block, and check=response response=@foo;

If would need to be smart enough to pick out the host piece so it can
issue the proper Host: when connecting to the internal IPs of the
servers.





More information about the nginx mailing list