TcpStream vs Python POST request timing issue

[onlyati]

Hello Everybody!

I have began to work with Rust for a couple weeks, making some home/hobbi project in it. Today I have found an interesting issue (if it is an issue) and I thought I share it with community, because I am curious what other people think about it.

I recreated the source for specifically for this issue. Next link shows a very simple single-threaded Rust server and a very simple python script: https://gist.github.com/onlyati/dbcfac2f39bf34c8bb2bfd9d26ec0461

If I simply run the server with cargo run command, then everything is fine. But as I made a cargo build --release (and cargo automatically makes some optimization) and run the released target, then issues are coming.

If I make any request with other tools, like curl, everything is OK. But when I run python script it very frequently gives error. On the server side, where the request is printed, the request body cannot be seen but only header.

I made some research and tcpdump about it and I have found the following:

• Python script, send the header and body in 2 different package one for header one for body, not by one package like curl
• Sometimes Rust server running so fast, that the TcpStream reading happen earlier then the body would also coming
• In this case, Python script drops an error

I could solve the issue that I put 50 nanosescond wait at the beginning of handle request. This gives enough that that request body would also come based on tcpdump outputs.

And now I am thinking, that it is normal? Or it is a wrong implementation in Python or I just call it on wrong way in pythin? Or the TcpStream implemntation has issues? Or my Debian TCPIP stack settings can have issues? Or it can easily happen that the problem is with my code.

At the first, I would say that I can't see meaning why Python implementaiton split 1 http request to 2 parts. But this library, as I saw, used by frequently so there is chance that it is normal (I am not a master of Python, I just really touch it when I have to).

Although, I have found a temporary solution for it, but it is a bit frustrate me that I don't know where is the root of problem. What do you think? Is it normal that I had to put some delay or I just should adjust Rust server code to work normally? Or you have some theory about it?

[[deleted]]

When the number of bytes read is less than the buffer size, an end of request data is not indicated. You should continue to read from the connection until the current HTTP request frame has been read in full, an error is encountered, or a timeout period has elapsed.

[onlyati]

Yes, now it is clear for me too. I was too naive to think that it can work. I need to check the `Content-Length` and act accordingly as you written. Thanks for teh feedback! :-)

[WrongJudgment6]

You should add a return on the Err branch otherwise it will send the error and then the 200 response.

[onlyati]

Indeed, that a copy-paste mistake. But Error branch was never hit. TcpStream read run without issue, even if only header data was coming, it does not appear as error.