The title says "not pausing" but the description says it is pausing and the problem is that it sends data too fast when unpaused. So isn't the title then completely wrong?

@bagder I see that only invoking of write call back from libcurl is paused. I believe that the underlying socket still receives data from server which is accumulated in socket buffer(Fix from #3240 looks like we are just skipping the read from socket, not pausing data exchange between the client and http server, not sure if it is possible in any way). So when we un-pause the connection, we are receiving more data probably because of all accumulated in the socket buffer.

The question is still what you say the problem is. Is it like the title says or is it like your description?

Reading the code, we don't have any consideration for CURLOPT_MAX_RECV_SPEED_LARGE when a transfer is unpaused and the cached data is delivered to the application. I think I would rather document this as a known behavior than trying to fix it, because it is going to be a rather kludgy fix - unpausing the transfer but still not actually receiving data because the draining of the cache isn't complete.

@bagder The title can go with the description. Please feel free to change it.
So, shall I assume that there wont be any fix on this in near term ?

The use case, I have is depending on the available bandwidth, I need to pause/resume data transfer till the bandwidth available. Please provide me any solution/pointers if you know of.

If you use HTTP/2 or HTTP/3, pause cannot be instant and it will continue to cache received data for a window-full amount of bytes.

The delivering of data faster than CURLOPT_MAX_RECV_SPEED_LARGE when unpaused is getting documented in #9430.