I am studying the way HTTP server is working (Wiced 3.1.2, NetX_Duo stack)
There are some findings which I cannot figure out.
Please, help if you know what is going on.
I have written a simple TCP client in C that can send data to HTTP server.
I am sending a properly formed HTTP request:
(I have removed some text for brevity; I am sending a C-type string; BSD socket is used; once connection is established I write buffer to the socket )
const char buffer = \
"POST /api/settings HTTP/1.1\r\n"
On the HTTP server end we receive data with the function: wiced_http_server_get_packet_data ( socket, packet, &request_string, &request_length ); It gets the packet which contains only HTTP Header. And request_string is pointing to the start of the Header.
After that, later on, I use wiced_tcp_stream_read(...) and get the HTTP body (of size Content-Length).
It seems that HTTP request is split into 2 parts. HTTP Header comes in the first packet. HTTP body comes in the next packet.
I cannot figure out who is doing the splitting of HTTP requests. Who is the middle men?
If I try to modify the first line of header, say, "QQQQ /api/settings HTTP/1.1\r\n", I get the whole message in the first packet (including the body)
Is it Netx_Duo that is looking for HTTP requests and on receiving them splits them into Header and Body with "\r\n\r\n" delimiter?
Or is it done somewhere above the tcp network stack and I am missing it? Or is it just magic?
I would be grateful for any help.
You could try to capture packet on the wire and/or air , too see who do it!
I have notice that when requests are sent from Firefox on ipad they arrive with a Header and a Body in one packet. So it seems that the splitting is done on the sender's side. It would be great to read somewhere about this kind of peculiarity.
The header/body splitting is pure client things.
i.e. Safari sends request with header/body splitted, Firfox sends request in one
However, the problem is the implement of HTTP server in SDK assumes the request
is one packet. Thus it does not works if you have header/body splitted request.
I think the http server needs fix to properly handle the request from Safari.
Thanks. Yes, I agree. Chrome on ipad also sends all in one packet.
As for the HTTP server, I had to modify it in order to accommodate our needs.
A TCP implementation can split application data as it pleases, that's a fundamental fact about TCP. You can get each header inside individual packets. Theoretically you can get individual characters each in its own packet.
Usually stream reassembly is handled for you by the TCP stack (e.g. socket read in Linux), but in WICED API you get individual packets, so you have to handle it yourself.
It seems like none of application-level protocol implementations on top of TCP in WICED handle fragmentation correctly. A similar bug is in websocket library for months now (that doesn't even compile).
I am going to lock this. Please open a new thread if you have follow up questions.