0fb43e4395
We have the encrypted() signal that lets users do extra checks on the established connection. It is emitted as BlockingQueued, so the HTTP thread stalls until it is done emitting. Users can potentially call abort() on the QNetworkReply at that point, which is passed as a Queued call back to the HTTP thread. That means that any currently queued signal emission will be processed before the abort() call is processed. In the case of HTTP2 it is a little special since it is multiplexed and the code is built to start requests as they are available. This means that, while the code worked fine for HTTP1, since one connection only has one request, it is not working for HTTP2, since we try to send more requests in-between the encrypted() signal and the abort() call. This patch changes the code to delay any communication until the encrypted() signal has been emitted and processed, for HTTP2 only. It's done by adding a few booleans, both to know that we have to return early and so we can keep track of what events arose and what we need to resume once enough time has passed that any abort() call must have been processed. Fixes: QTBUG-126610 Pick-to: 6.7 6.5 6.2 5.15 5.12 Change-Id: Ic25a600c278203256e35f541026f34a8783235ae Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit b1e75376cc3adfc7da5502a277dfe9711f3e0536) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> |
||
|---|---|---|
| .. | ||
| access | ||
| kernel | ||
| selftest | ||
| socket | ||
| ssl | ||
| CMakeLists.txt | ||