Serve from cache but fire request to upstream server to increment page view counter

Jonathan Matthews contact at
Wed Apr 4 12:27:32 UTC 2012

On 4 April 2012 13:17, Quintin Par <quintinpar at> wrote:
> Thanks Appa.
> Why would you say this is not reliable? Is there data or experience to
> suggest? The semantic is awesome. Precisely what I’ve been looking for.

I'd also be interested in discovering any unreliability of this
mechanism, as I'm planning to use it for some real-time logging

The weaknesses that I've discovered thus far, which I think should all
be fixed -- or at least modified as indicated below -- are

* The client connection is held open until the post_action call completes
* The response code returned to the client is the post_action's response code
* The access.log entry logged reflects the post_action's URI, response
code and (possibly; I forget) content length

All of these render it difficult to use post_action as its name
implies - to be competed *after* the client request is completely
dealt with.

I hope that at some point in the future, we'll be able to use
post_action in a way which is invisible to the client, and to the
logs. Perhaps with a post_action directive flag, indicating that any
calls to this specific post_action URI should stay out of the logs and
the client's view.


> On Wed, Apr 4, 2012 at 1:39 PM, Antonio P.P. Almeida <appa at>
> wrote:
>> There's the post_action directive. But AFAIK is not that reliable.
>> I would use Lua with the "new" cosocket API and do an HTTP request.
>> Here's an example of a library built around it that talks with a Redis
>> backend:
>> As stated post_action is another option:
>> --appa
>> _______________________________________________
>> nginx mailing list
>> nginx at
> _______________________________________________
> nginx mailing list
> nginx at

Jonathan Matthews
London, Oxford, UK

More information about the nginx mailing list