Question on Empty GIF module

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

Hello Rt,

Thursday, April 24, 2008, 11:37:51 AM, you wrote:

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!

location = /dummy.gif {
proxy_pass http://backend;
}

location = /empty.gif {
internal;
empty_gif;
}

in the backend app just add ‘X-Accel-Redirect: /empty.gif’ to the header
set and
then close connection and then “proceed to do (non-web) operations in
the
background based on the query string data.”

but there is one issue: Set-Cookie header from app will be passed by
nginx to
the client, but P3P header wont. I recently noted it:
http://www.lexa.ru/nginx-ru/msg17278.html

Hello!

On Thu, Apr 24, 2008 at 11:52:35AM +0700, Denis F. Latypoff wrote:

I have a tiny web app that listens for web requests for a certain .gif file.
would like if I used it like this:
If the above would work as I hope it would, then I could even modify my app so

then close connection and then “proceed to do (non-web) operations in the
background based on the query string data.”

IMHO, post_action will be much better here. Something like:

location / {
empty_gif;
post_action /post;
}

location = /post {
internal;
proxy_pass http://my_upstream_servers;
}

Maxim D.