| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make it clear that the functions will return false if the socket was already
disconnected.
Fix the QLocalSocket example snippet to handle that case correctly by checking
state() before attempting to wait.
Fixes: QTBUG-50711
Change-Id: I4ab4062446a0041a35a3a1d65a19202ffa103298
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
| |
And add a test for it so it can no longer happen in any current or
future implementation.
Change-Id: I3214aa90595e291b1e1c66befe185cfe1ea7bc6b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-61771
Change-Id: Ideafe6f8f81c156e941f0548c152021b01b606a1
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Found while cleaning up SPDY remains: I've noticed that for H2 case
I never check if incomingSslConfiguration is nullptr or not, but
the code several lines below - does it, which looks kind of moronic.
This configuration is initialized when the delegate is created, so
no need to have this if-statement. Instead, assert, making this
behavior a requirement.
Change-Id: I90fb84337be925a3288252aa2491b4c23d6c6cbb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
| |
Found while preparing SPDY retirement.
Change-Id: I30f923fdeb0f6f0b5e808a3e7b7d81ddb9c4ef12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
| |
It's not a failure state, we just need more data. It is handled properly
in other functions.
Change-Id: I9450a78c71a3f4fe9506a7a79de6efa2db08697c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The reason it wasn't working before was a couple of things:
1. Due to an extra 'else' it would not process the SEC_I_RENEGOTIATE
or SEC_I_CONTEXT_EXPIRED branch.
2. The peerCertVerified boolean was not only wrong, but also
broke renegotiation even if the 'else' wasn't there.
My previous attempt to fix it ended up being a noop, so:
Reverts e21fa577dde32849fdaa744f30ad3b23d63b7214
Change-Id: Ifbad55d4bb066b7566bb88cead48e329cbd574f9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\
| |
| |
| | |
Change-Id: I371c5ae1af6f58e32e579671f485b92b586e0b76
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While working with HTTP/2, we are not re-sending failed requests.
In case we receive a GOAWAY frame, we properly handle it by
processing some active streams if possible, and aborting streams
that will not proceed further with ContentResendError. But it's
possible that some server failed to send us GOAWAY (for example,
it died) or closed the connection not finishing the streams that
were still active and valid (ID <= value from GOAWAY frame).
Now that we will not re-connect, there is no reason to be quiet
about us not progressing - emit RemoteHostClosedError on any
remaining active stream/request we cannot process further.
Fixes: QTBUG-77852
Change-Id: I4cd68a1c8c103b1fbe36c20a1cc406ab2e20dd12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 543769666f18f79bd6ebd6119a39834aafc2b0df)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The _q_error slot has a special case for RemoteHostClosedError,
where the current channel's state is 'idle' and no request/reply
is in progress. The comment states that:
"Not actually an error, it is normal for Keep-Alive connections
to close after some time if no request is sent on them. No need
to error the other replies below. Just bail out here. The _q_disconnected
will handle the possibly pipelined replies."
_q_disconnected, indeed, takes care about pipelined replies ... calling
'ensureConnected' even if we have 0 replies in pipeline, which makes
zero sense to me and results in QNAM endlessly trying to re-connect
to the server.
Fixes: QTBUG-77852
Change-Id: I6dcb43b36a6d432bc940246a08f65e1ee903fd24
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I realized this is a potential scenario where we will have leftover
data, but it wasn't covered.
Change-Id: Ibaf1015bf2aee120e4a4d98888925b88ecb6ddfd
Reviewed-by: Jesus Fernandez <jsfdez@gmail.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I9823da32168e99bbece2f8337d0bd4d33e6d634c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the end range of a byte range in a HTTP request is skipped the download
manager adds 0 it its place when resuming that download.
When there is no end range given the value is skipped.
Task-number: QTBUG-77867
Change-Id: I52358c94cf56c88217fcc91abb102ed393ac7242
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* initialize the structure used as argument to ioctl SIOCGIFMEDIA
The ioctl in ifType(...) returned -1 and set errno to EFAULT, thus
the code to determine the interface type was not executed.
Task-number: QTBUG-76408
Change-Id: Ib69c2c0cd4dda3604d568adf9746e0c9a280e9a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This should help when things are moving fast, and downloads and
network object are destroyed before the callbacks finishes.
Change-Id: I1f65965bd61efc2e641d03eb071f23e684dd5c44
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\ \ |
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/configure.json
src/gui/util/qtexturefilereader.cpp
src/gui/util/util.pri
tests/auto/gui/util/qtexturefilereader/tst_qtexturefilereader.cpp
Change-Id: I2bc4f84705b66099e97330cda68e0b816aceb9cc
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As is said in RFC7301 in section 3.1 [1]:
Protocols are named by IANA-registered, opaque, non-empty byte strings
[...]. Empty strings MUST NOT be included and byte strings MUST NOT be
truncated.
[1]: https://tools.ietf.org/html/rfc7301#section-3.1
Change-Id: I2c41fa99984a53cc58803e5a264d06edac964cc6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|/ /
| |
| |
| |
| |
| |
| | |
The source code is still only using the old negative define check.
Change-Id: I7e2775d6d4664cb5b802b0a40fb3f1711c8f6915
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As is said in RFC7301 in section 3.1 [1]:
Protocols are named by IANA-registered, opaque, non-empty byte strings
[...]. Empty strings MUST NOT be included and byte strings MUST NOT be
truncated.
[1]: https://tools.ietf.org/html/rfc7301#section-3.1
Change-Id: I38168ac570a433807e16121d5dec46d4ac73c4bf
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\|
| |
| |
| | |
Change-Id: Id7954ada1f8658d3b1da5e8241a09f2d201a7c56
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some servers seem to be unable to properly calculate our window size
from a delta we send via WINDOW_UPDATE frame immediately after our
client preface and the SETTINGS frame. The remote replies with a
GOAWAY frame blaming flow control error. Guessing what's this
magic number they use seems to be not feasible, we now use a
half of what we had before.
Fixes: QTBUG-77308
Change-Id: I41dacfd25a395a27003f330d01b6d8d60b8f407c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
qmake/generators/unix/unixmake2.cpp
src/plugins/platforms/cocoa/qcocoawindow.mm
Change-Id: Iba7aa7324f35543e0297a3680956420058cd3630
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While it is correct not to call the functor when the context object has
been destroyed, we still need ot clean up the slotObj. It's a low-
probability memory leak: the context object has to disappear while
waiting for a host resolution, and for repeated requests for the same
host the cache takes over anyway.
Task-number: QTBUG-76276
Change-Id: Id9daf391353b8252443f3186a7d504d70c553b24
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\ \ |
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/io/qresource.cpp
Change-Id: I54917f72444a621bd08aeaa15f5d17415993144d
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Lookups performed via QHostInfoRunnable must not synchronously call
the user-code's receiver objects, as that would execute user-code in
the wrong thread. Instead, post a metacall event through the event
loop of the receiver object, or the thread that initiated the lookup.
This was done correctly for the trivial cases of empty host name or
cached results, so the code generally existed. By moving it from a
global function into a member function of QHostInfoResult, we can
simply access the required data to construct and post the event.
As we process that posted event, we need to check that the context
object (which is already guarded via QPointer) is still alive, if
we had one in the first place. If we had one, and it's deleted, then
abort.
[ChangeLog][QtNetwork][QHostInfo] Functors used in the lookupHost
overloads are now called correctly in the thread of the context object.
When used without context object, the thread that initiates the lookup
will run the functor, and is required to run an event loop.
Change-Id: I9b38d4f9a23cfc4d9e07bc72de2d2cefe5d0d033
Fixes: QTBUG-76276
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
OpenSSL 1.1.x libs must be suffixed otherwise it will use the system ones which on API-21 are OpenSSL 1.0 not 1.1
Fixes: QTBUG-76884
Change-Id: I7d4052be68cf7dc65f74a48da8e1e37182056a5e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Need to pass correct buffer size
Change-Id: I19cb65114f49decc225cd807d59f1f08ad6b70c9
Fixes: QTBUG-76212
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/access/qhttpthreaddelegate.cpp
Change-Id: Id47b977587e2d713c16ac17e63c5ec80c2f05ee9
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QNetworkAccessManager::connectToHostEncrypted()/connectToHost()
creates 'fake' requests with pseudo-schemes 'preconnect-https'/
'preconnect-http'. QHttp2ProtocolHandler should handle this
requests in a special way - reporting them immediately as
finished (so that QNAM emits finished as it does in case of
HTTP/1.1) and not trying to send anything.
We also have to properly cache the connection - 'https' or
'http' scheme is too generic - it allows (unfortunately)
mixing H2/HTTP/1.1 in a single connection in case an attribute
was missing on a request, which is wrong.
h2c is more complicated, since it needs a real request
to negotiate the protocol switch to H2, with the current
QNetworkHttpConnection(Channel)'s design it's not possible
without large changes (aka regressions and new bugs introduced).
Auto-test extended.
Fixes: QTBUG-77082
Change-Id: I03467673a620c89784c2d36521020dc9d08aced7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I685000c4f33fb3707b2102fae0b58092107dc8f0
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As noted in RFC7230 Section 6.1 the 'Connection' options are case
insensitive.
https://tools.ietf.org/html/rfc7230#section-6.1
Change-Id: I80b98d82eaa5572d38a6c3f99383bc059ec91c54
Fixes: QTBUG-76990
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.pri
Also required s/solid\.color/solidColor/ in a couple of places in:
src/gui/painting/qpaintengine_raster.cpp
Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous code handled only some error codes, in a very inefficient
way, for some code paths. This change standardizes error handling using
a helper function that maps winsock WSAE* codes to Qt error codes.
The test for connecting to unreachable hosts or ports is now more
generic, and enabled on Windows, where it passes in local tests,
but dependency on network configuration still makes it fragile,
so ignoring some failures without completely skipping the test.
[ChangeLog][Network][Windows] Correctly emit errors when trying to
reach unreachable hosts or services
Change-Id: Icaca3e6fef88621d683f6d6fa3016212847de4ea
Fixes: QTBUG-42567
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In auto-test-enabled builds, QHostInfoCache can be enabled and
disabled using qt_qhostinfo_enable_cache() at any time. We cannot rule
out that users use this function, or, indeed, that the auto-test never
gets a threading stress-test. Under the assumption, then, that
QHostInfoCache::enabled can be set by any thread at any time, and is
read by any thread using QHostInfo::lookupHost(), we're presented with
a data race, thus UB.
Fix by making the accesses to QHostInfoCache::enabed atomic. Relaxed
operations are suffcient, as the bool is the only data of interest in
these situations. In particular, access to the cache itself is
protected by the cache's mutex.
We use std::atomic<bool> because QAtomicInteger<bool> doesn't exist on
all implementations, but std::atomic<bool> must. Commit a0faf9e2366 set
the precedent that it works.
Change-Id: Ia1766753bb54c5fe8d8447b51a49a96a7a853eef
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The plain bool variable wasDeleted is set to true in the
QHostLookupManager dtor before the call to clear(), which calls
waitForDone() on the thread pool performing the lookups. All tasks on
the thread pool start by checking this variable so as to return early
when destruction is in progress. But the check was outside the
mutex-protected area, so as a non-atomic load, without a
happens-before relation to the write, this is a Data Race, thus UB.
Fix by moving the check past the mutex locking into the critical
section. This way, tasks that were waiting for the mutex after seeing
no wasDeleted before get the message reliably.
This does not introduce a dead-lock, since the call to waitForDone()
is outside any mutex protection leaving a window for the tasks to
obtain the mutex and react on wasDeleted.
Change-Id: Ied4b9daa7dc78295b0d36a536839845c4db2fb78
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
|
|\ \ |
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
.qmake.conf
Change-Id: I936be3c0df2b9845ff6a85eb3d4442cdabe63d37
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I51fc7aae246916e585b21b4e7da1fc5a4ac392fd
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When calling waitFor{ReadyRead,Disconnected} it will wait for data but
if the data is already received and the read notification has been
queued (and there's no more data coming in) it will return false.
By checking if a read notification has been queued and then handling
this we can easily take care of this scenario.
Fixes some flaky tests which missed the read data in waitForDisconnect
and similar.
Fixes: QTBUG-38385
Change-Id: Ic05d59883c1175783e56ff1822b6636c35aec874
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we end up in the connected state then we should pass on any
remaining data immediately instead of waiting until the next time we get
a read notification.
The other `case`s in the switch might be able to do something similar,
but I don't want to introduce that logic now in case it breaks something
else, the Connected branch is small and simple to deal with.
Should severely reduce flakiness with socks proxy in CI under pressure.
Task-number: QTBUG-76367
Change-Id: I0965d4c62a29a25ce6b8dd60862a464279aef0b4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Ryan Chu <ryan.chu@qt.io>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QNetworkReply implementation for Qt for WebAssembly now supports
usage of the QNetworkAccessManager::sendCustomRequest, making it
possible to send requests with custom verbs.
[ChangeLog][QtNetwork][QNetworkAccessManager] Fixed
QNetworkAccessManager::sendCustomRequest for Qt For WebAssembly.
Fixes: QTBUG-76775
Change-Id: I9394ffef110fce4ed2c877893631bedc7631f71e
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
|
|\|
| |
| |
| | |
Change-Id: I4cb91777e7ae9f462fa219d5b9ebeb277fde49c3
|
| |
| |
| |
| |
| |
| |
| | |
The header argument is optional
Change-Id: I035e11db5ee70183274afb48ba67c4d3ed2f615d
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
not to resolve merge conflicts on every 5.13->dev merge.
Change-Id: Id41a7efff52148fe46bedcde828646694fd1764d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I912bd8851c390302414d3dfb3c8220df5a0d5630
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using a http proxy (and presumably other proxies) we might have
failed/aborted (aka "finished") the request and _then_ receive a
"proxy authentication required" message from the proxy. In this case
there is no spdy/http2 reply in the queue, so asserting is wrong.
Change-Id: Id9b76b580299f6a6cd6efad62d6aaf63183816fb
Fixes: QTBUG-76426
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In some scenarios with QNAM we call socket->close, leading to a flush,
leading to an error, leading to another error emission... To work
around this scenario we stop trying to close the socket if the network
channel is already closing.
Change-Id: Id15504f476484ce61f11ba83a5755ceb5f581f9b
Fixes: QTBUG-76567
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/io/qstorageinfo_unix.cpp
src/network/ssl/qsslsocket_openssl.cpp
Change-Id: Ibc9ce799bef62d60d616beaa9fbde8ebeadfbc20
|