Question on Empty GIF module

[Rt Ibmer]

>You mean "posted by Denis"?

Yes, sorry about that.

>In sort: post_action registers callback that will be called after request 
>will be processed by usual handlers (in this case - by empty_gif 
>module).  It evaluates after response has been sent to client, 
>so client sees no delay in request processing.

I see. So its not actually doing a "POST" type of operations.  Rather, it is posting (really just forwarding) the same request to the url specified by the post_action, correct?

Is it possible to have the post_action be load balanced across a set of backend servers (like the way proxy_pass works) or will it only work with one specific server?  If that later is the case, could I work around that by running another instance of nginx on another port on the server, setting the post_action to hit a url on that instance of nginx, and then have that instance of nginx use proxy_pass to distribute the requests among multiple servers? This is of course just for the backend processing since the empty gif would already have been served.

>The only disadvantage of post_action as of current implementation 
>is that it blocks connection, i.e. following keep-alive request 
>won't be processed until post_action terminates.

Can you please explain the implication of this in some more detail, as I am not very familiar with the details on how all the connection stuff works under the hood?

For instance, lets say that the server handling the post_action takes 500ms to execute before returning the 204 No Content response. What connection is actually being blocked during this period? The browser that originated the request has been satisfied immediately by empty_gif so I know it doesn't see this delay, but what does?

Perhaps what you are saying is that no matter how many requests come in at the same time that are destined for post_action, that nginx can only process those one at a time? So that my app doing the background work (that post_action is talking to) would only get one request at a time? Then I would imagine that under load the requests within nginx could build up to a point where the backlog was too load and eventually run out of connections or break some how?

At any rate, how difficult of a change is it to make post_action so that it does not block, and are there any near-term plans for this?

>Docs for post_action doesn't exist (yet).  There are some relevant 
>russian mailing list posts, but I can't recall anything in 
>English.

Are there any optional parameters or attributes that can be specified with the post_action I should know about?

>And of course really best way do things is to write logs and just process them as needed.

Depending on how this all works out, it may be worthwhile down the road to rewrite our app to process off the log files. Am I correct to assume that I can use an access_log directive inside the area where empty_gif is used, so that these specific gif requests are logged to their own log file separate from the other types of requests that nginx is handling?

>Closing connection isn't really needed since empty_gif returns 
>response with Content-Length set, and even HTTP/1.0 browsers will 
>see response before connection will be closed.  This will block 
>subsequent requests within keep-alive connection though, see 
>above.

>You have to return any valid response.  Simple "204 No content" will do.


Perfect, I'll change it to do that.

Thank you very much Maxim for all your help with this! It is deeply appreciated!!




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ