I recompiled without passenger (--with-http_ssl_module --with-http_gzip_static_module --with-cc-opt=-Wno-error) and to my surprise, the interrupted request issue has disappeared. This means that having the passenger module compiled into an application changes some aspect of timeouts for all requests, independent of whether you have turned the passenger directive on or not. Wow... Now I understaby BrindleFly - Nginx Mailing List - English
Here is nginx version (note: although it is compiled with passenger, I have not turned on the passenger directive in nginx.conf): nginx version: nginx/1.2.6 built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --with-http_ssl_module --with-http_gzip_static_module --with-cc-opt=-Wno-error --add-module=/usr/local/rvm/gems/ruby-1.9.by BrindleFly - Nginx Mailing List - English
Anatoly, See my other reply. I can take Passenger entirely out of the mix and still reproduce (using Nginx, Unicorn, configured via upstream). So this is not Passenger in this case (although usually I suspect it for most other issues ;) ). Joeby BrindleFly - Nginx Mailing List - English
The Unicorn test I ran disabled the passenger module and passed on requests via upstream in Nginx - but still returned a partial request. The only test that returns a full request is to bypass Nginx entirely and go direct to Unicorn. So based on this, it seems specific to my Nginx configuration. I find it hard to believe this is a generic defect in Nginx. It must be configuration related, rightby BrindleFly - Nginx Mailing List - English
I'm struggling to find the source of a timeout. I am running Nginx (1.2.6), Passenger 3.0.18, and Rails 3.2.11. On serving one long running request, I find the results (CSV file) truncated after being returned from the client. The Rails application however continues to serve up the data until complete, at which time it reports: Couldn't forward the HTTP response back to the HTTP client: Itby BrindleFly - Nginx Mailing List - English