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