Postponing responses to requests

Maxim Dounin mdounin at
Mon Mar 15 21:08:53 MSK 2010


On Mon, Mar 15, 2010 at 12:23:37PM -0400, plw at wrote:

> I'm trying to figure out how to get some code working in an 
> NGINX module we
> are writing. The basic idea is that requests come in to our 
> module, and we
> make callouts from the module to both some external code and to 
> an upstream
> HTTP interface. We then want to send responses to the requests.
> The bit that we are a little confused about is how to manage our 
> responses
> correctly. Our code looks a bit like this.
> - Get request in our request handler
>   - Do some work that will trigger an async callback later (from 
>   a library)
>   - Return NGX_DONE to say "leave us alone for now"
> - Get async callback from our handler
>   - Issue upstream request (using upstream module)
> - Get upstream response
>   - Do some more processing before sending response (potentially 
>   much later after more async work)
> The problem occurs in that last step; we can do our async 
> processing and manage the upstream requests OK, but as soon as 
> we get our response from the upstream module, we find that 
> finalize_request is called and a response is sent. However, we 
> want to hold off until later sending the response.
> We'd like to be able to just say "don't send a response on this 
> request just now, even though the upstream request has 
> returned". I think perhaps the underlying issue is that we are 
> just issuing an upstream request not a subrequest, but I'm now 
> quite confused, and it would be very helpful if somebody could 
> give me some helpful hints, or else point me at some 
> documentation of how to do this, or just at some sample code we 
> could read through for ideas.

Basically you have two options:

flags.  It works for small responses and only when appropriate 
protocol module supports it (proxy and memcached do).

2. Install output filter and do anything you want with response.  
This works always, but it's up to you to correctly implement it.

Maxim Dounin

More information about the nginx mailing list