The test in general is fine, but it was making an assumption that the first 5 readyRead emissions would never result in the whole message being received. In certain scenarios with slowdown however it was still possible that we would receive the whole message after just a few readyReady emissions. While I didn't check it's most likely due to a mechanic in the QNetworkReply machinery where we suppress some emissions if we know there's more data just about to be available. Task-number: QTBUG-88943 Change-Id: I0cf06edb34d4e86cc8a42c0f1cd7e8c35765f6ee Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> |
||
|---|---|---|
| .. | ||
| hpack | ||
| hsts | ||
| http2 | ||
| qabstractnetworkcache | ||
| qdecompresshelper | ||
| qhttpnetworkconnection | ||
| qhttpnetworkreply | ||
| qnetworkaccessmanager | ||
| qnetworkcachemetadata | ||
| qnetworkcookie | ||
| qnetworkcookiejar | ||
| qnetworkdiskcache | ||
| qnetworkreply | ||
| qnetworkrequest | ||
| CMakeLists.txt | ||
| access.pro | ||