nginx filter to concat text to a response body

[Joshua Zhu]

Hi,

On Sat, Sep 22, 2012 at 1:28 PM, Filipe Silva <fs20063 at outlook.com> wrote:

> Hi Zhu,
>
> I tried taobao's module and it works like a charm if nginx is configured
> as a web server:
>
> server {
> listen       80;
> server_name  localhost;
>
> location / {
>     footer "<!-- $date_gmt -->";
>     index index.html;
> }
> }
>
> The result is a html comment with a gmt date like <!-- 1234567890 -->
> added to the end of the response body.
>
> But if configured like a reverse proxy it does not add the comment.
>
> server {
> listen       80;
> server_name  localhost;
>
> location / {
>             proxy_pass         http://127.0.0.1:8080/;
>     footer "<!-- $date_gmt -->";
> }
> }
>
> Well, this simple nginx location configuration points the traffic to a
> upstream web server. As expected, on return I don't get the nginx's default
> index.html, but the upstream html page instead, with the difference that
> the comment <!-- 1234567890 --> is not added.
>

Strange. It should work. What is the 'Content-Type' of the output of your
upstream server, by the way? By default the 'footer' module only processes
contents in 'text/html'. You can add more content types by using the
'footer_types' directive though.

And I tested the following configuration. The footer was correctly added.

    server {
        listen      80;
        server_name localhost;

        location / {
            root   html;
            index  index.html index.htm;

            proxy_pass http://127.0.0.1:8080;
            footer "this is a footer\n";
        }
    }

    server {
        listen      8080;
        server_name hi;

        location / {
            root   html2;
            index  index.html index.htm;
        }
    }


>
I'm pretty sure I'm missing something here. I'm starting to believe that if
> I want to write to a response body served by a upstream server a filter may
> not be the answer.
>
> I've tried evanmiller.org guide and I found the section "3.2. Anatomy of
> an Upstream (a.k.a Proxy) Handler" (
> http://www.evanmiller.org/nginx-modules-guide.html#proxying) and I have
> the impression that this might help me finding the answer, but I'm failing
> to reproduce the example because at the moment I'm not as familiar with the
> guts of an handler as I am with a filter.
>
> Anyway, I don't even know if an handler will do the trick. So any help is
> welcome :)
>

There is no doubt that the module should be a filter, not a handler. The
filters will be called no matter whether you are accessing an upstream
server or not, since they are _output body_ filters.

Regards,

-- 
Joshua Zhu
Senior Software Engineer
Server Platforms Team at Taobao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120922/341d0228/attachment-0001.html>