Making subrequests from handler

[Igor Sysoev]

On Fri, Nov 27, 2009 at 10:26:34AM +0800, agentzh wrote:

> On Fri, Nov 27, 2009 at 10:01 AM, Peter A Leonov <gojpeg at gmail.com> wrote:
> > I'm just wondering if it is possible to perform any subrequests this way.
> 
> I think it makes little sense to say "subrequests can only be issued
> from output filters rather than content handlers". Why? Because output
> filters are just plain C functions called by content handlers
> themselves, usually in this form:
> 
>      ngx_int_t
>      my_content_handler(ngx_http_request *r) {
>          ...
>          rc = ngx_http_send_header(r);
>          ...
>          return ngx_http_output_filter(r, cl);
>      }
> 
> The output filter chain is a plain C function call stack. So if an
> output filter can issue subrequests, then logically so does a content
> handler :) There's no real difference in C's context here and no magic
> here.
> 
> > The code of SSI module tells me than the filter can do so with ease. But
> > what about handlers? All about the latest nginx 0.8.*.
> >
> 
> The "echo" module and the "fancyindex" module both issue subrequests
> from content handler. There's also a workable case in this thread
> (although shaun eventually gave up the subrequest model due to an
> issue of canceling pending subrequets, well, you don't need
> cancellling subrequests in your scenario anyway):
> 
>     http://www.ruby-forum.com/topic/199392
> 
> > The thing I'm trying to implemet is a simple JavaScript method
> > subrequest(uri, callback). Any number of subrequests may be waited at the
> > same time, and when finishef be combined in random order.
> 
> Given the "postponed chain model"  currently implemented in Nginx, if
> one does not buffer and rearrange the outputs of the subrequests using
> a custom output filter himself, then the order of the subrequest
> outputs will be exactly the *same* as the order they are originally
> issued even though they're actually run in parallel.

Correct.

> I must say the basic idea of subrequests called by a scripting
> language like JS is definitely great. Why not scripting all the Nginx
> internal infrastructure directly for our apps? It's really a pity to
> just use Nginx as a boring proxy to the bloated FastCGI apps or even
> to an Apache monster ;)
> 
> We're also going to turn coco lua to a first-class citizen in Nginx
> module development just like C. Transparent non-blocking I/O is also a
> plus here when compared to plain C coding. It's interesting to do the
> same with other interpreters if the C-level coroutine support is in
> place.

The main issue with language embedding is handling out of memory case.
Some languages do not check allocation results (perl), some simply exit
on failure.

I will probably add V8 javascript.

> > Could you please help me figure it out or just point to a source code?
> >
> 
> Please see the source code of the ngx_http_subrequest function in the
> core and the standard postpone filter for more details. The "echo"
> module may help you experimenting various aspects of both parallel and
> sequential subrequests from a content handler.


-- 
Igor Sysoev
http://sysoev.ru/en/