General Development Inquiry
eran.kornblau at kaltura.com
Mon Jun 8 05:06:10 UTC 2020
> 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!
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.
More information about the nginx-devel