• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 40 subscribers
  • Views 249 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220R: POST token processing by host

Oleg Oleg1
Prodigy 60 points
Part Number: CC3220R
Other Parts Discussed in Thread: CC3200

Hi,

I'm porting an app from CC3200 to CC32xx SDK (latest version up to date).

The old CC3200 SDK/NWP used to process GET as well as POST tokens for files in /www/ folder in SFFS using the same SimpleLinkHttpServerCallback function.

The new CC32xx SDK/NWP calls this callback function only for GET requests. For POST requests, another SimpleLinkNetAppRequestEventHandler gets called with a complete HTTP request metadata/payload as param (I have to tokenize it myself then). This itself is not a problem, the problem is that for using SimpleLinkNetAppRequestEventHandler, I have to keep the

#define slcb_NetAppRequestHdlr  SimpleLinkNetAppRequestEventHandler

which increases the g_StatMem global struct size proportionally to SL_ASYNC_HTTP_SRV_EVENT_LEN * MAX_CONCURRENT_ACTIONS ((1600-220) * 5 = 6900 bytes).

This looks to me like an absolute overkill in terms of memory consumed.

When looking at "Figure 9-6" in "9.1.3.2 Static Pages With Host Tokens" from swru455l.pdf, it is indeed documented only for GET requests.

But I also see in source/ti/drivers/net/wifi/source/netapp.c, function

_SlReturnVal_t _SlNetAppEventHandler(void* pArgs)

...

switch(pHdr->GenHeader.Opcode)

...

case SL_OPCODE_NETAPP_HTTPPOSTTOKENVALUE

Which hints me that at least SL driver is aware of this feature, not sure about NWP.

So my question is: is host POST token processing really supported or not?

Thanks,

Oleg

  • 0
    TI__Guru 61556 points

    SimpleLinkHttpServerCallback - handles host tokens.

    SimpleLinkNetAppRequestEventHandler - handles the entire content of the request (when the resource is not available in the ROM or in the FS). 

    For POST (that is not using the defined RESTFUL API), the 2nd callback makes more sense.

    I'm not sure i understand your comment regarding g_StatMem. The CC3220 host driver is configured to dynamic memory (SL_MEMORY_MGMT_DYNAMIC).

    Have you changed this?

    Br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Prodigy 60 points

    Hi Kobi,

    thank you for an answer.

    Yes, my project uses SL_MEMORY_MGMT_STATIC (in order to get rid of potential malloc issues like fragmentation).

    My question was about the support of the host POST token processing status of the new chip.

    Thanks,

    Oleg

  • 0 in reply to Oleg Oleg1
    TI__Guru 61556 points

    I believe the host token won't be supported for POST (I'll need to verify). What is resource name that you are using? is it one of the RESTFUL API or a file that exists on the file system?

    One of the main reasons to use the dynamic memory was to avoid reserving the memory for the worse case scenario. Maybe, you can reduce the size if you know that the you will only receive shorter messages. 

  • 0 in reply to Kobi Leibovitch
    Prodigy 60 points

    It's a .html file on the file system which sends a url-encoded POST request that contains user-defined tokens (starting with __SL_P_U).

    Dynamic memory management approach has some downsides: apart from previously mentioned malloc fragmentation issue, I would have to extensively test the system under all possible conditions in order to make sure that I can handle the real worst case memory load correctly. Provided that I use preemptive RTOS with multiple tasks that can use sl_* functions, this task becomes really complex.

  • 0 in reply to Oleg Oleg1
    Prodigy 60 points

    After playing with it for a while, I can confirm that CC3220 actually does support user-defined host POST tokens via SimpleLinkHttpServerCallback. The 'Content-type' header of the POST request must be 'application/x-www-form-urlencoded' (also stated in datasheet).

    The problem is that all Webkit-based web browsers (like all iPhone browsers and desktop Safari) somehow break this mechanism and CC3220 falls back to the SimpleLinkNetAppRequestEventHandler. Very interesting.

  • 0 in reply to Oleg Oleg1
    TI__Guru 61556 points

    I would recommend using the dynamic memory management as this is our default method and as such it is mainly tested by our testing team and customers.

    br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Prodigy 60 points

    The original question was about processing POST tokens one by one, this functionality is supplied by the NWP and has nothing to do with memory management in SL driver. This used to work before with CC3200 and now is partially broken. I have to find out why.

    I'll take a look later what is different in complete POST data sent by Safari and non-Safari browsers, and will keep you posted.

    Thanks,

    Oleg

  • 0 in reply to Oleg Oleg1
    TI__Guru 61556 points

    I understand the original question, but in CC3220/3x we recommend using the slcb_NetAppRequestHdlr  for the POST content.

    The dynamic allocation will allow you to use this method without the extra memory consumption.

    br,

    Kobi

  • 0 in reply to Kobi Leibovitch
    Prodigy 60 points

    I understand your point, and would probably go this route if nothing else helps.

    Thanks,

    Oleg