Hi,

On Sat, Sep 22, 2012 at 1:28 PM, Filipe Silva <fs20063@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
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel