"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.
