General Development Inquiry

Eran Kornblau eran.kornblau at
Sun Jun 7 06:11:24 UTC 2020

> 2) I'm actually working on a second module/system aside from the one mentioned in my previous post.  This might actually be an easier question?  It's using a custom upstream (like the memcache one) to talk a binary protocol to another daemon with requests/responses.  For the most part it works, but there is one oddity that I can't seem to resolve - the daemon can respond with an HTML code/header set and then a response body.  My upstream process_header function is setting up all of the respective HTTP headers (content length, etc.) and buffer positioning to stream the response and NGINX is issuing it to the browser.  However, it doesn't finalize the request, instead waits for more data (which isn't coming, the response is complete) from the daemon and then times out after a minute and closes the connection.
> My suspicion is that the 'built-in' upstream handing is designed around servers that close the connection after the response is issued.
> But my daemon doesn't need to do that, so I'm trying to essentially use upstream with keepalive.  Do I also need to provide an output filter to track the response length myself and properly mark the last buffer/end of chain so that the request finalizes without closing the upstream connection?  Or is there some variable that I'm missing?  Any suggested examples to look at?
>From your description, I'm guessing you didn't set r->upstream->length, you need to set it to the response size you're expecting. The upstream input_filter decrements u->length by the number of bytes read each time, when it reaches zero, the request is finalized.


More information about the nginx-devel mailing list