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

[Quintin Par]

This seems to very risky.

One more question:

The whole reason why I’d use post action is to take the time off from doing
a SSI. i.e. serve a page from cache in light speed and then let post action
take its own sweet time to complete.

But from Jonathan’s response I infer that a post actions response code is
passed to the client. Which means the client is made to wait till the post
action is complete. Right? If yes, that defeats the purpose.

On Wed, Apr 4, 2012 at 5:57 PM, Jonathan Matthews
<contact at jpluscplusm.com>wrote:

> 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
> shortly.
>
> 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.
>
> J
>
> > On Wed, Apr 4, 2012 at 1:39 PM, Antonio P.P. Almeida <appa at perusio.net>
> > 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: https://github.com/agentzh/lua-resty-redis
> >>
> >> As stated post_action is another option:
> >>
> >> http://wiki.nginx.org/HttpCoreModule#post_action
> >>
> >>
> >> --appa
> >>
> >> _______________________________________________
> >> nginx mailing list
> >> nginx at nginx.org
> >> http://mailman.nginx.org/mailman/listinfo/nginx
> >
> >
> >
> > _______________________________________________
> > nginx mailing list
> > nginx at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx
>
>
>
> --
> Jonathan Matthews
> London, Oxford, UK
> http://www.jpluscplusm.com/contact.html
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20120405/9c1fe841/attachment.html>