> 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.

Eran
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Reply via email to