Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Here's a series of 18 smallish commits that cleans up buffer use all over libcurl. I want to make sure the receive buffer is only used for actually receiving data, and ultimately make sure our different buffers don't all reuse
And since the buffer is actually used to receive data and some of our code cannot handle streaming data completely, the receive buffer must have a certain size to still let libcurl function properly. One patch in this set thus sets the minimum
Test 1060 fails miserably if we allow the receive buffer to be smaller than about 16K, so I'm now considering either
Yes, that's for sure. The CONNECT code is written to work with a fixed-size buffer and if the response is larger than so, it will break. So yes, that's a separate issue that should be worked on separately. But I would also expect that it is a very rare happening to see such big response to a CONNECT.
The buffer is needed to receive FTP, HTTP CONNECT responses etc so already at this size things risk breaking and smaller is certainly not wise.
To make it suitably independent of the receive buffer and its flexible size.
... to properly use the dynamically set buffer size!