endel
commented
11 months ago Hi @hunkydoryrepair, thanks for the detailed report!
I forgot we had this 500ms limitation. I think we can increase the default limit + have some detection for aborted requests to avoid waiting forever.
For customization I think we can provide expressify(app, { readBodyTimeout: 3000 }) + process.env.UWS_READ_BODY_TIMEOUT for customization, what do you think?
It's great to see Pixels getting popular! I'd love to see it supporting Colyseus financially if possible 💖 Cheers!
hunkydoryrepair
We've run into occasional issues getting "request size did not match content length".
It is very sporadic, but ultimately determine that the timeout, which requires the full content is received within 500ms is causing problems. I'm not sure if this is 500ms for the full content body, or if timeout resets with each packet received. Our payloads are around 1500 bytes, which is often 2 packets.
Scenarios where we end up getting this error:
Server under too much load. In this case, the timeout seems to happen before the packet is processed, although I cannot prove that. However, I would expect if server is overloaded, if the socket service took priority over the setTimeout, we wouldn't be getting these errors more during server overload. (Another possibility, servers are overloaded enough to cause packet loss due to buffer overflow).
network packet loss. If a client is having packet loss issues, the 2nd or 3rd packet of the request may come in more than 500ms after the initial packet. We get this more with users in Asia trying to hit our servers in US.
Would it be possible to make that timeout value configurable? Obviously, we don't want the client to hang forever with open socket because they sent 1 bad request, but in our case, it needs to be a little more patient.