Can't read HTTP response in multiple small chunks

Issue by bierkandt-bosch Monday Sep 23, 2019 at 08:34 GMT Originally opened as https://github.com/Bosch-AE-SW/cddk-oss/issues/267

Function CellularHttp_GetResponse() found in https://github.com/Bosch-AE-SW/cddk-oss/blob/e8f6f497a52495617ddb0e09043840abbfb1cb8f/core/connectivity/cellular/include/Kiso_CellularHttpService.h#L113 fails and results in undefined behaviour if the user does not provide a sufficiently sized data buffer to hold the full HTTP response. This is a currently undocumented limitation of the implementation and should at least be made visible to the user.

Example: A user performs a GET request on some large web-resource (like a firmware-image). The image is 1MB in size. The modem performs the download, stores the file on its internal flash memory and notifies the user. The user consequently wants to read the response, but can't provide the 1MB required for a single read. They instead perform a read with 10KB expecting the file download to automatically offset with each read. The function does not compare the required and provided buffer sizes nor does it offset the read-start-address after each read. So it proceeds to download 10KB, over and over again. Best-case result, the user reads the same 10KB each time and has invalid data. Worst-case result, the AT IO-handling gets tripped up by the unfinished download and subsequent AT IO fails, requiring a hard-reset.

The API does currently not state whether or not multiple reads on a single response are allowed. On ublox modems, this is just a download of a file on the modem-internal flash. So reading small chunks from a HTTP response is supported. Quectel supports a similar mode-of-operation via AT+QHTTPREADFILE.

[ ] Decide if a HTTP response can be streamed, rather than consumed whole. Design, document and implement accordingly.

This ties into the already very limited support for HTTP in the current AT IO-handling (see #197; should be figured out first!)

eclipse-archived / kiso

Can't read HTTP response in multiple small chunks #23