> 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
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel