Reassembling of GET/POST
General
No replies yet. Be the first to reply.
Join the discussion.
General
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: Reassembling of GET/POST
by Kei ·
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.
RE: RE: Reassembling of GET/POST
by kschwi ·
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.
RE: Reassembling of GET/POST
by kschwi ·
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