Question on Empty GIF module
Rt Ibmer
rtibmx at yahoo.com
Thu Apr 24 08:37:51 MSD 2008
Is it possible to use the empty GIF module to return the 1x1 pixel to the client, BUT then to also pass the request along to an upsteam server so that the query string data on the request can be processed?
Here is the quick background on what I am trying to do...
I have a tiny web app that listens for web requests for a certain .gif file. Requests hit the web app like this "http://webappurl.com/dummy.gif?data1=xyz&data2=abc".
My web app then immediately returns a dummy gif of its own and closes the connection. Then it proceeds to do (non-web) operations in the background based on the query string data.
For performance reasons it would be FAR more efficient (at least from the browser's perspective) if nginx could return the 1x1 pixel instead of my app, but then still pass the request onto my app server so it can process the query string data. I guess another way of asking is whether nginx would work as I would like if I used it like this:
location / {
empty_gif;
proxy_pass http://my_upstream_servers;
}
So in the above case, would it still pass the request on to my upstream servers? Or would the empty_gif statement essentially end the nginx processing at that point?
If the above would work as I hope it would, then I could even modify my app so that instead of returning a gif it just closed the connection. This is because empty_gif would already have satisfied the browser request, so there would be no point in bothering to return a gif from my app as well because it would just get dropped on the floor. But I'm not sure if just closing the connection from my app like that would then cause nginx to think the upstream was down or broken and take it off line, so maybe I still have to return the gif?
Thanks in advance!
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
More information about the nginx
mailing list