Couldn't forward the HTTP response back to the HTTP client: It seems the user clicked on the 'Stop' button in his browser

Question

Problem i am facing is:

I am issuing a request from browser via ajax and send the request for processing, once the ajax call is made i show a popup with progress bar, the popup remains on page for roughly any where between 2 to 4 mins and closes abruptly. When i see the request via chrome network tab i see that request is stalled for the same duration for which popup displays. I see that the logic is executing in the background as expected but the popup did not wait for the response and closes before it is supposed to.

I have set the log level to 7 and i see the below information

if there are 50 records to be processed i see this information before each of those 50 records start the processing(i.e i see the below line 50 times)

[ pid=29768 thr=70024879087720 file=abstract_request_handler.rb:472 time=2016-08-30 08:06:43.250 ]: Accepting new request on main socket

and lastly i see this

[ pid=29571 thr=139782938920704 file=ext/nginx/HelperAgent.cpp:923 time=2016-08-30 08:10:32.682 ]: Couldn't forward the HTTP response back to the HTTP client: It seems the user clicked on the 'Stop' button in his browser.

I suspect its some timeout issue but not sure if its at passenger level or ngnix level.

I have tried setting various ngnix timeout parameters to a higher value but it has not help.

  proxy_read_timeout 400s;
  client_body_timeout 180s;
  keepalive_timeout 180s;
  client_header_timeout 180s;

**I suspect it might be some issue with passenger config, but not sure.**

Can anyone please let me know what I can do so that the request continues without abruptly ending

Miriam

If the processing is too slow you might need to use some kind of background proccessing, so the requests ends quickly and the user can close the windows and come back later to a custom url to see the progress. If the problem is the actual file upload you should warn the user about max file size or maybe try some custom ajax uploading system. – Salta

Thanks for the response, actually the process is such that i cannot proceed it in the background. Its a long running process. – Miriam

Why can't you do that on the background? what's the process? if the process is long and you need it to finish, you can't hope the connection just stay open since you can't fully control it. You can fake a foreground processing using a background process and ajax calls on the view to display the current background process progress. – Salta

Yes, thats how its done, an ajax call is made, however before the ajax call should succeed, the popup which show the progress prematurely closes and doesnt wait for the actually process to complete. I am not sure is its something at passenger level or ngnix level. i suspect something is timing out but not sure what – Miriam

Answer 1

It is a File upload/download ? For download I uses in the associated location

proxy_buffering             off;
proxy_request_buffering     off;
chunked_transfer_encoding   on;
client_body_timeout         3600;
proxy_read_timeout          900;

For file upload, I uses

client_max_body_size    10m;
client_body_timeout     600s;

(warning, if you have a return to a location in the associated location it should be set in the first location)

Or a sort of event over http ? With chunk ? Keepalive ? For chunk I uses:

proxy_buffering         off;
proxy_buffer_size       4k;
proxy_request_buffering off;
proxy_cache             off;
underscores_in_headers  on;

(for info on chunk, NGINX corrected an old bug in 1.11.2 if chunk with sub_filter directives)

In your browser, in Debug Window in Network tab what is the error or status shown after the request fails ?
Status code and/or Reponse header ?
Sometimes there may also be a reply/info in Preview.

Drogue

Hello Arfy, its not file upload or download. It a http request with chunk on – Miriam

Answer 2

From your question, it is not very clear who is actually terminating the request -- the browser, nginx or even passenger itself.

The best practice to ensure that a long-running HTTP connection will not be garbage-collected and closed prematurely is to ensure that some sort of small data is always sent through the connection at certain intervals, e.g., try sending a couple of spaces or comments every 90 seconds (or some such), and see if that fixes the issue.

Bots

hi, how do i identify what is causing the timeout, there must be a way – Miriam

@opensource-ios, you should use tcpdump; mdoc.su/f/tcpdump.1; regardless, the best idea is to ensure you protect yourself from it in the first place, because if it's the browser causing it, it's not like you can just change the settings of all the browsers that your users do -- best way to protect is to ensure something always gets sent on the wire at all times, at certain intervals. – Bots

thats the revised solution i am implementing, but i wanted to know what is causing the timeout? and can there be any setting which was be modified to check the same – Miriam

As mentioned, the only sure way is tcpdump. Browsers aren't supposed to keep connections open forever, if you're not sending anything over a connection, it's pretty much irrelevant who's actually going to be closing it, because it's the extended inactivity that's a sure way to have the connection closed within a couple of minutes in most User-Agents. – Bots