Serve from cache but fire request to upstream server to increment page view counter
contact at jpluscplusm.com
Wed Apr 4 12:27:32 UTC 2012
On 4 April 2012 13:17, Quintin Par <quintinpar at gmail.com> 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
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 perusio.net>
>> 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: https://github.com/agentzh/lua-resty-redis
>> As stated post_action is another option:
>> nginx mailing list
>> nginx at nginx.org
> nginx mailing list
> nginx at nginx.org
London, Oxford, UK
More information about the nginx