nginx filter to concat text to a response body

[Filipe Silva]

Hi,
If I setup to 2 nginx servers, one as the reverse proxy and the other as the web server - exactly what you did on your example - the footer is added to the response body.
Well, that works and confirms that filter is the way to go :)
However, what I'm using here as web server is not nginx but an apache server.
The 'Content-Type' is text/html. The 'Content-Length' grows from 146 (apache web server port 8080) to 163 (nginx reverse proxy port 80) but the footer "this is a footer\n" (17 bytes long) is not added by the module.
I'm taking a look at apache default configuration to check if there is something that is making nginx behave differently.  Below are the response headers from each case:
Response headers from reverse proxy nginx 80 
HTTP/1.1 200 OKServer: nginx/1.3.5Date: Sat, 22 Sep 2012 08:13:08 GMTContent-Type: text/htmlContent-Length: 163Connection: keep-aliveLast-Modified: Thu, 06 Sep 2012 13:39:44 GMTEtag: "81333-b1-4c9089fc7c802"Vary: Accept-EncodingContent-Encoding: gzip
Response headers from web server apache 8080
HTTP/1.1 200 OKDate: Sat, 22 Sep 2012 08:13:13 GMTServer: Apache/2.2.16 (Ubuntu)Last-Modified: Thu, 06 Sep 2012 13:39:44 GMTEtag: "81333-b1-4c9089fc7c802"Accept-Ranges: bytesVary: Accept-EncodingContent-Encoding: gzipContent-Length: 146Keep-Alive: timeout=15, max=100Connection: Keep-AliveContent-Type: text/html On the meanwhile if you have a clue what is happening I'll be thankful. 
Thank you,
Filipe S
Date: Sat, 22 Sep 2012 14:21:58 +0800
Subject: Re: nginx filter to concat text to a response body
From: zhuzhaoyuan at gmail.com
To: nginx-devel at nginx.org

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


_______________________________________________
nginx-devel mailing list
nginx-devel at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120922/e075dd0e/attachment.html>