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.

  • Resolved

RTOS/CC3220: HTTPClient_sendRequest returns error when header length exceeds HTTPClient_BUF_LEN

Prodigy 70 points

Replies: 3

Views: 198

Part Number: CC3220

Tool/software: TI-RTOS

While using HTTP Client, I see that if header length +3 (\r\n\0) exceeds HTTPClient_BUF_LEN (which is 256 by default), it cannot be sent.
And the current solution is told here https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/693714?RTOS-how-to-rebuild-http-client-library-

a) Would it not be better if HTTPClient_setHeaderByName/HTTPClient_setHeader checked the header length and returned error if so?

b) For the next release of cc32xx sdk, can calling SlNetSock_send multiple times for one header line, be considered as a solution when header name and header value cannot be concatenated?

Thanks & Best regards,
Caglar

  • Hi Caglar,

    The points you bring up about the HTTP header length limitations and how we could handle it are interesting.

    For suggestion a, returning an error at this stage could be useful for debug purposes. However, since the buffer size is fixed at compile time, you would still be stuck with a buffer too small to fit the header. Thus, you would still have to make the change in the library to increase the buffer size. Of course, you could rework the library so that it doesn't rely on a fixed-size buffer but I do not think that is something we would change in the foreseeable future.

    For suggestion b, your workaround to handle headers larger than the buffer size makes sense and I will submit that as a feature request. However, I do not know how soon it can be implemented and so it might be worthwhile for you to implement that locally on your end to workaround any HTTP client issues you are facing, assuming that increasing the HTTPClient_BUF_LEN is not feasible in your system.

    Regards,
    Michael
  • In reply to Michael Reymond:

    Thank you for the response.
    As you said, suggestion a is for debug purposes.
    May I share my implementation for suggestion b with TI when it is done as I will be glad to contribute to this product?
    Thanks & Best regards
    Caglar
  • In reply to Caglar Ivriz:

    Hi Caglar,

    We always appreciate forum users who share their own fixes, and if you provided an implementation for suggestion b I will definitely share it with the team that develops the HTTP library. No guarantees that it will be taken by that team and used as-is for future releases of the HTTP library, but I'll make sure it gets to them.

    Regards,
    Michael

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.