Progress Monitoring HTTP Requests in Installed Apps

This is a note about the pitfalls of progress monitoring HTTP requests sent from an installed app (i.e. not web app running in a browser).

Ideally, we’d like to know how long an HTTP POST is going to take, and update the percent-completed visually so that when it reaches 100% the operation is neatly finished as indicated.  This turns out to be very difficult.

Problem: Methods that Both Send and Receive

The main problem has to do with methods (functions) that both send the request and receive the response.   All methods in the Chilkat.Http class both send and receive.  For example, Http.PostJson3 is a method that sends a POST w/ a JSON request body, and receives the response (which is also typically JSON).   When we begin sending the POST, we have no idea of how big the response will be, or the “think time” of the server (the amount of time it takes for the server to process the received request and begin sending the response).   Chilkat Http chooses one direction for monitoring progress.  Generally, if the HTTP request is a GET or DELETE (or something with no request body), the PercentDone is measured while receiving the response.  It is assumed that a small HTTP request is quickly sent, and as soon as the response header is received, the PercentDone events can start flowing based on the size indicated by the Content-Length header.   However, if the response is chunked, then there is no Content-Length header and the application has no way of knowing how much data is coming before the final 0-sized chunk is received.  In this case, it’s impossible to monitor PercentDone progress.

If, however, the HTTP request is a POST, PUT, etc. with a large body, such as for multipart/form-data uploads or perhaps a POST to send a large GMail (via GMail’s REST API), then the PercentDone events are based on the sending of the request.  In the case of GMail, there’s likely a long “think time”, which is unknowable, after which the response is small and quick.  This would explain the behavior if PercentDone events progressed to 100%, but then there was a significant delay until the operation was actually completed.

Chilkat REST: More Flexibility for Separating Send from Receive

Chilkat.Rest and Chilkat.Http are both classes for HTTP. Most tasks can be accomplished using either.  One reason for creating the newer Chilkat.Rest class was to provide an API that was capable of separating the send and receive into separate methods.   An HTTP request can be accomplished by three separate calls instead of one.  For example: Rest.SendReqSb, followed by Rest.ReadResponseHeader, followed by Rest.ReadRespBodyString.   This allows an application to monitor the progress of each call individually.  The problems of server “think time” and chunked responses still exist.