# Order of execution of nginx filters

**URL:** <https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897>\
**Category:** NGINX\
**Created:** [July 5, 2016, 6:15am UTC](https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897 "2016-07-05T06:15:43Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [July 5, 2016, 6:15am UTC](https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897/1 "2016-07-05T06:15:43Z")

</div>

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](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](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,

---

<div class="post-metadata">

**Author:** ![RaghavanS\_Gopal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c67d28/32.png) [@RaghavanS\_Gopal](https://www.ruby-forum.com/u/RaghavanS_Gopal)\
**Post date:** [July 5, 2016, 6:07pm UTC](https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897/2 "2016-07-05T18:07:49Z")

</div>

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:  
[Emiller’s Guide to Nginx Module Development – Evan Miller](http://www.evanmiller.org/nginx-modules-guide.html), specifically  
[Emiller’s Guide to Nginx Module Development – Evan Miller](http://www.evanmiller.org/nginx-modules-guide.html#filters-body) 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  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![RaghavanS\_Gopal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c67d28/32.png) [@RaghavanS\_Gopal](https://www.ruby-forum.com/u/RaghavanS_Gopal)\
**Post date:** [July 5, 2016, 11:00pm UTC](https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897/3 "2016-07-05T23:00:29Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![RaghavanS\_Gopal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c67d28/32.png) [@RaghavanS\_Gopal](https://www.ruby-forum.com/u/RaghavanS_Gopal)\
**Post date:** [July 6, 2016, 2:34pm UTC](https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897/4 "2016-07-06T14:34:07Z")

</div>

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 D.

> **[nginx](http://nginx.org/)**

---

<div class="post-metadata">

**Author:** ![RaghavanS\_Gopal](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c67d28/32.png) [@RaghavanS\_Gopal](https://www.ruby-forum.com/u/RaghavanS_Gopal)\
**Post date:** [July 7, 2016, 2:43pm UTC](https://www.ruby-forum.com/t/order-of-execution-of-nginx-filters/244897/5 "2016-07-07T14:43:39Z")

</div>

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