0
votes

I'm writing a STM32 C function (using lwIP netconn) that accepts a HTTP Post Request with a file "attached". I've used a form to pick a file to transfer from the PC to the MCU. I use the following line to capture the request:

netbuf_data(inbuf, (void**)&buf, &buflen);

The buflen gets a value of 624 but the "Content-Length" header is 75093. Here is the buffer captured:

POST /upload.cgi HTTP/1.1
Host: 192.168.0.10
Connection: keep-alive 
Content-Length: 75093
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://192.168.0.10
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary46gMrRDRRGlHEkwC
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://192.168.0.10/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

Why is the buflen different from the Content Length? The sample code I have searches for the string "octet-stream" to know when the binary data begins but with such a small header it doesn't find it.

Unfortunately I do now have Wireshark to know the exact size of the HTTP packet. Should I be using another method to capture the buffer that is safe with RTOS?

Thanks.

1
The Content-Length header specifies the length of the data, not the header. - Some programmer dude
I also recommend you learn a little bit more about HTTP and how to tell when the header ends and the data begins. And remember that HTTP 1.1 is based on TCP which is a streaming protocol, without explicit beginning or end, or fixed packets. You might need more than one receive-call to receive all data. - Some programmer dude

1 Answers

0
votes

With netbuf_data you get slice of data from stream. And stream may have any data. Try any telnet client (Putty) to connect to your host and type something. You will see it in buffer.

And now you should parse such stream. This stream have format HTTP 1.1 and this stream have nothing with STM32 and TCP in common: different layer (see OSI model) Read about HTTP headers. I see Content-Type: multipart/form-data Are you sure you want to parse this?

Why is the buflen different from the Content Length?

Because buflen is length of slice you captured, Content-Length: 75093 is about HTTP

Should I be using another method to capture the buffer that is safe with RTOS?

No, you do right way