Hi,
I have a problem with the web server when the browser splits a get or post. Attached is a wireshark trace splitt request.pcapng.zip (1.0 KB). .108 is the PC and .31 the web server.
I’ve seen this problem on different browsers. Normally it helps to close the browser and to reopen it. But it would be better to handle split requests by the web-server.
Any idea how to prevent this or have a workaround?
The web-server in my limited implementation has a 1k input buffer.
Cheers,
Knut
Hi,
There seems to be a problem with the request packet from the browser.
From the Wireshark log you sent, it is different from the first packet sent from the PC to WIZ550WEB and the fifth POST packet.
The first packet did not transmit contents corresponding to contents length, and the fifth packet transmitted contents.
“a_switch.cgi” seems to have been created by you, please check if the firmware you have created will return NOT FOUND if there is no content in the POST packet.
I do not know what client you are using.
So please try again with a verified client like POSTMAN.
In addition, it might be helpful if you give me a packet log of a normal working situation.
Hi,
I bumped into this problem again. Chromium for Linux came with this problem again. Attached you find a trace from starting the web-server, opening a page (with Login). Trace 195 / 196 show one package that is send while pressing the save button (User action at the browser). I don’t understand why the browser does not use the window size of 2k that is more than sufficent for this packet.
Anyway the first packet #195 is analysed without any action and the second is dropped. Do you have an idea how to get around this problem?segment.pcapng.zip (18.6 KB)
Cheers,
Knut
19-Feb-2018:
I reread the data sheet and rechecked the wiresharks. It seems that Chromium gives a shit on the “don’t Fragment”-flag in the IP-header. I saw severeal packets that are fragmented - without any need (500bytes in the first packet and 5 byte in a second). While the 5500 does not support any fragmentation and Chromium does not care about this flag one has to reassembler data based on logic. 
Today I had a chat with a TCP/IP specialist. The flags in the header are not relevant for the behaviour to splitt HTTP data into several transmission packets! TCP/IP is a byte stream oriented protocol. Hoping that a browser sends data in one “packet” is mostly valid, but without any underlying reason. In one article I found:
“In HTTP (starting with HTTP/1.1), recipients MUST support chunked encoding.”
Transmitting data from the browser to the Webserver can be chunked or in one block. The HTTP-token “Content Length:” is an indicator for valid data from a browser to the webserver vice versa. Is this token missing there is no data, otherwise it has to be checked if the data following “/n/r/n/r” are as long as the Content Length value.
Conclusion: Combining chunked transmission is a missing feature of this web-server.
Cheers,
Knut
Copyright © 2017 WIZnet Co., Ltd. All Rights Reserved.