XSLT2 - new module, reviews and opinions needed :)

[Maxim Dounin]

Hello!

On Wed, Oct 21, 2009 at 06:30:17AM -0400, piotreek wrote:

> Ok, we've written asynchronous resolver and it seems to work properly.
> 
> However, we have problems with subrequests.. We thought about them at the very beginning, we tried to understand their mechanism by reading SSI filter source code, but it was really complicated, so we've written our own module to do that.
> 
> For example - when I use subrequest in simplest way:
> 
> ngx_http_myfilter_body_filter(..)
>   if(r == r->main) {
>     (...)  
>     ngx_http_subrequest(...)
>   }
>   ngx_http_next_body_filter(...)
> }
> 
> result of that subrequest will be send to the client - we don't want that.
> Ofc I can do something like that:
> 
> if(r == r->main)
> {
>    ngx_http_subrequest(...)
>    return ngx_http_next_body_filter(r, in);
> } else {
>    return ngx_http_next_body_filter(r, NULL);
> }
> 
> but this isn't probably best way to do that... This will "kill" any subrequest, not only ours. In SSI this problem is solved in some way, but I can't find how. ;)

In ngx_http_ssi_include():

%     if (set) {
% 
%         ...
% 
%         flags |= NGX_HTTP_SUBREQUEST_IN_MEMORY|NGX_HTTP_SUBREQUEST_WAITED;
%     }

> Another problem - reading result of subrequest in registered callback.
> In SSI there is a function (registered as callback for some subrequests):
> 
> static ngx_int_t
> ngx_http_ssi_set_variable(ngx_http_request_t *r, void *data, ngx_int_t rc)
> {
>     ngx_str_t  *value = data;
>     if (r->upstream) {
>         value->len = r->upstream->buffer.last - r->upstream->buffer.pos;
>         value->data = r->upstream->buffer.pos;
>     }
>     return rc;
> }
> 
> Result is taken from r->upstream, but why? Why upstream module is used? What will happen if subrequest handles static file?

It works only with replies from memcached and/or proxy modules.  
This limitation is documented here:

http://sysoev.ru/nginx/docs/http/ngx_http_ssi_module.html#commands

(looks like relevant page on wiki isn't really relevant, google 
translate is the rescue).

> And last, but not least - parallel subrequests.
> Evan Miller says that this is really complicated etc. 
> http://www.evanmiller.org/nginx-modules-guide-advanced.html#subrequests-parallel
> SSI source code isn't clear for me, but what about that code:
> 
> for(...) {
>    if (ngx_http_subrequest(...) != NGX_OK)
>       return NGX_ERROR;
> }
> 
> This should enqueue some subrequest and nginx should process them "in parallel" (almost, as it's one thread). Am I wrong? What more can I do to simulate parallelism?

No, just calling ngx_http_subrequest() in order is enough.  
Everything else will be handled by nginx itself.

Maxim Dounin