This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3220: Bug in OtaHttpClient

Part Number: CC3220


Hello,

we just found a bug in OtaHttpClient function HttpClient_RecvSkipHdr().
I suppose this function should just skip the HTTP header and return the data-size left without the header. But we ran into an edge-case when the first received segment only contains the HTTP header and the return value is 0. This sounds rare but it happend rather often when using python -m http.server.

Here is a proposed fix:

  • Hi Norman,

    We'll look into this. Thank you for your suggestion.

    Best,
    Kevin
  • Hi Norman,

    In your scenario (and typically), you should better use the "HttpClient_RecvSkipHdr()" with the point to contentLen (last paramter).

    If you provide the pointer, the function will retrieve the expected content length. Then the application should keep polling the rest of the frame using HttpClient_Recv.

    See the following example for reference:

    Br,

    Kobi

    uint32_t contentLen, recvLen=0;

    int16_t Len;

    ....

    Len = HttpClient_RecvSkipHdr(SockId, pRespBuf, RespBufSize, &contentLen);

    while (Len >=0 && recvLen < contentLen)

    {

        recvLen += Len;

        Len = HttpClient_Recv(SockId, pRespBuf+recvLen, RespBufSize-recvLen, 0, MAX_EAGAIN_RETRIES);

    }

    if(Len < 0)

    Error Handling

  • Hello,
    seems like a valid point, although you should look at the TI-OTA library who's calling HttpClient_RecvSkipHdr(), it's this function in "simplelink_cc32xx_sdk_1_60_00_04\source\ti\net\ota\source\CdnClient.c" :

    int16_t CdnClient_RecvSkipHdr(int16_t SockId, uint8_t *pRespBuf, int16_t RespBufSize)
    {
    return (HttpClient_RecvSkipHdr(SockId, pRespBuf, RespBufSize, NULL));
    }

    Which deliberatly leaves the last argument empty...
  • Hi Norman,

    That's a real issue (in the OTA library).
    I believe it will be solved if the error check will be changed as following:

    if (0 > pOtaLib->RecvChunkSize)

    The handling of the "Len==0" is wrong and shouldn't be considered as error.


    The rest of the frame content will be read based on the OTA internal logic.
    We'll add the fix to one of the next SDKs.

    Br,
    Kobi