"No olvides, no traiciones, lo que llevas bien dentro de ti. No olvides, no traiciones, lo que siempre te ha hecho vivir."
On Wed, Aug 23, 2017 at 8:33 AM, André Warnier (tomcat) <a...@ice-sa.com> wrote: > On 23.08.2017 09:48, Grigor Aleksanyan wrote: > >> Hi Simon, >> >> If I understood your approach correctly, then this will work only if I am >> the one that implements the client, right ? What about cases when client >> is >> browser or curl, not my c++ app ? >> > > Yes, that is one of the issues. Most browsers, after they send a request > to a server, wait for about 3 minutes for an answer (which may be just one > byte, but "something"). If they do not get the beginning of an answer > within that timeframe, they will > - close the connection to the server > - automatically display some internal error page to the effect that "this > server is not responding, please repeat your request later" > The only way to stop this behaviour, at the browser level, is to have some > "applet" builtin (in your previous application page), which "polls" the > server regularly, to get some kind of "ack" back, which resets the > browser's timer. > > For expected long-running requests on the server, such a thing is usually > part of the application, and shows itself in the browser as some kind of > "progress bar", moving dots etc. That is /also/ a way to avoid that the > user "panics" at not getting a response right away, and starts clicking > left and right (which would also cause the browser to close that connection > without waiting for the response). > > All of this, is a legacy from the original design of HTTP, which was > originally designed for > - client sends a request to a server, to get back "one thing" (a HTML page > or a file) > - the server sends back the requested resource (or an error if it doesn't > have it) > and then everyone is finished and the next such transaction is something > totally disjointed and different. > Over time, this original design has been "patched" a number of times, to > accomodate more and more sophisticated interactions, as the WWW has > "exploded" much beyond the original designers expectations. (And also as > the capabilities of clients and servers have exploded). > But one consideration has always been to maintain backward compatibility, > so there are some basic principles which are difficult to modify, and > application designers have to cope with them. > Until someone invents - and manages to get adopted - something radically > new and different, to replace HTTP. Websockets is a step, but it's still > somewhat of a patch onto HTTP. > > Yes, you have to implement the "retry/pooling" logic in the client. Today , browsers running javascript apps make this possible. The client side is like: 1- POST start big job URL response comes with job id 2- while (!end) { GET job result URL + job id response comes with false or with the job result if (response comes with false) { sleep 10 seconds } else { end = true; manage result of big job } } That is something you can do with javascript and modern browsers. Search for AJAX: Async HTTP requests.