General Development Inquiry

[Eran Kornblau]

> Hmmm, hopefully this works because I subscribed with digest.  Thank you very much for the feedback, I now had an idea of where to focus (I had a rough idea but this made it clearer).  And now I know what the issue is but have no idea how to resolve it.
> 
> My module was setting the upstream length as you suggested, hence my confusion.  So I flooded the ngx_http_upstream code with debug statements to hunt down why the code around line 3614 (which calls finalize on the upstream length reaching zero) wasn't working.  Turns out, the value was -1, which, if I read the code correctly, indicates that upstream is complete when connection is closed (consistent with what I was seeing).
> 
> More debugging, turns out that my custom process_header method is setting the correct length to process, but immediately after that can the nginx server internally calls process_headers, which transfers all of the values between the upstream and request headers and...then...sets the upstream length to -1!
> 
> Gah!  So now I know what's wrong, but have no idea how to address it!
> There's no indicators or flags that I can see in the process_headers method to have it not reset the length to EOF!
> 
> jmh
> 
I think you should set it in the input_filter_init function, instead of process_header, this is what the proxy & memcached modules do... This function is called after process_header, so it won't get reset.

Eran