Piotr Sikora Wrote:
-------------------------------------------------------
> If you want to go that route then I believe that
> you could re-use a lot of
> code from ngx_supervisord[1]. Most of the code
> below line 993 ("nginx <>
> supervisord communication" comment) does exacly
> what you need (creating
> "fake request", connecting to upstream outside of
> "upstream {}" confing,
> etc).
>
> One thing you should know upfront is that I needed
> requests which would be
> totally independent from any real connections /
> requests (ngx_supervisord
> communicates with supervisord even when there are
> no requests - to shut down
> idle backends, for example), and that's why there
> is a lot of code to create
> "fake" connections, events and configs in
> ngx_supervisord_init. I'm pretty
> sure you could get away with pointing most of them
> to data from original
> request...
>
> Also, responses from supervisord are quite small,
> so I'm forcing nginx to
> read them into memory. You might need to use temp
> files for bigger things.
>
> [1] http://labs.frickle.com/nginx_ngx_supervisord/
>
> Best regards,
> Piotr Sikora < piotr.sikora@frickle.com >

My original version of this module (long-poll with a single backend, dynamically determined based on the incoming request), does something very similar to what you're doing. For the incoming request, it figures out the appropriate backend then configures the request's upstream and kicks off the proxying. For the multi-backend version, I'll likely need to do something similar to what you've done (i.e. creating requests completely separate from the actual, live request). I figure the trickiest part will be building those requests and getting them in to state that's usable by nginx.

I haven't entirely given up on the subrequests yet, though.

Thanks,
Shaun