Forum: NGINX Order of execution of nginx filters

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F286ada5a9e11b32532bb5bbea90dc35?d=identicon&s=25 Raghavan, Gopal (Guest)
on 2016-07-05 06:15
(Received via mailing list)
Hi,

I have the following three directives:

location = /hello {
                 hello_world;
                 hola_mundo on;
                 bonjour_monde on;
}

hello_world is an nginx handler module that provides content “hello
world”
hola_mundo and bonjour_monde are filters that add to the chain strings
“hola mundo” and “bonjour monde” respectively.


Here is the output:
curl  "http://localhost:8090/hello"
hello worldhola mundobonjour monde


Switching the filter directives in location block has no impact on
output string.

For eg:

location = /hello {
                 hello_world;
bonjour_monde on;
                 hola_mundo on;
}

Here is the output:
curl  "http://localhost:8090/hello"
hello worldhola mundobonjour monde


How do I control the order of execution of filters?
I already looked at objs/ngx_modules.c and auto/modules. My custom
handlers and filters are not listed there.

One thing that I observed is that the order of listing the load_module
modules/*.so in conf/nginx.conf does impact the order of execution of
the filters.

Is there any other trick to adjust the execution order within the
location block?

Thanks,
1266aa99d1601b47bbd3ec22affbb81c?d=identicon&s=25 B.R. (Guest)
on 2016-07-05 18:07
(Received via mailing list)
AFAIK you do not control the order of filters, and when you are building
a
filter, you deal with data on-the-fly, which means your filter might be
invoked with a partial response coming from other filters.
Moreover, the module needs to 'win' its selection on a specific event.

I suggest you read some available literature (ex:
http://www.evanmiller.org/nginx-modules-guide.html, specifically
http://www.evanmiller.org/nginx-modules-guide.html... which
seems
to implement something close to what you wish).

​There is most probably more competent people to that matter who would
give
you better docs, but this is a head start I guess.​
---
*B. R.*

On Tue, Jul 5, 2016 at 6:06 AM, Raghavan, Gopal
<gopal.raghavan@here.com>
2420805745aab873cac60e8f8c1bccee?d=identicon&s=25 Charles Orth (Guest)
on 2016-07-05 23:00
(Received via mailing list)
Hi Gurus,

I'm new to nginx...
I would like to define upstream handler in HTTP without a HTTP server
listener. From SMTP/POP3/IMAP I would like
to use the upstream handler for my http endpoint. Thus requiring
http_upstream initialize, create a request, hand the request off to
upstream for processing and finally having HTTP upstream handler return
the entire response to my handler.
I haven't found any examples or patches where I can leverage HTTP
upstream from Mail service perspective.
Does anyone have a suggestion or an example?

Thanks
Charles
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2016-07-06 14:34
(Received via mailing list)
Hello!

On Tue, Jul 05, 2016 at 05:00:03PM -0400, Charles Orth wrote:

> I'm new to nginx...
> I would like to define upstream handler in HTTP without a HTTP server
> listener. From SMTP/POP3/IMAP I would like
> to use the upstream handler for my http endpoint. Thus requiring
> http_upstream initialize, create a request, hand the request off to upstream
> for processing and finally having HTTP upstream handler return the entire
> response to my handler.
> I haven't found any examples or patches where I can leverage HTTP upstream
> from Mail service perspective.
> Does anyone have a suggestion or an example?

This is not something you can do.  Mail and http are different
modules, and you can't use http module features in the mail
module.  If you want to use upstreams in mail, you have to
reimplement them there.

Practical solution is to use one address in mail (e.g.,
127.0.0.1:8080) and additionally balance requests using http
reverse proxy, e.g.:

mail {
    auth_http 127.0.0.1/mailauth;
    ...
}

http {
    upstream backends {
        server 127.0.0.2:8080;
        ...
    }

    server {
        listen 8080;

        location /mailauth {
            proxy_pass http://backends;
        }
    }
}

--
Maxim Dounin
http://nginx.org/
2420805745aab873cac60e8f8c1bccee?d=identicon&s=25 Charles Orth (Guest)
on 2016-07-07 14:43
(Received via mailing list)
Thanks Maxim,
The loopback feature you described is the work around we're using.
However, the new service I'm attempting to implement, it is costly on
several fronts.
My impression of reimplementation of upstream was what I was suspecting
all along.

Thanks
This topic is locked and can not be replied to.