Both SPDY and HTTP/2 work with a single qhttpnetworkchannel (and this means one
socket per qhttpnetworkconnection). Normally, HTTP/1.1 connection is using up to 6
channels/sockets though. At the moment a failure to negotiate SPDY/HTTP/2 leaves us
with a downgraded HTTP/1.1 connection (with only one channel vs. default 6).
Since we initialize channels (and establish connections) in a 'lazy' manner
it's ok to pre-allocate all 6 channels and then either use 1 (if SPDY/HTTP/2
indeed was negotiated) or switch back to 6 in case of failure.
Change-Id: Ia6c3061463c4d634aaed05ce0dde47bfb5e24dd8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
For the windows file system engine, we add an extra macro to use
library loading if configured to do so, but avoid it on WinRT, as
none of the symbols would be found.
We also QT_REQUIRE_CONFIG(library) in the library headers and
exclude the sources from the build if library loading is disabled.
This, in turn, makes it necessary to clean up some header inclusions.
Change-Id: I2b152cb5b47a2658996b6f4702b038536a5704ec
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Make it iterate the addresses available looking for an IPv4 address,
when that's what it needs, instead of just assuming the first entry in
the list (when non-empty) is IPv4.
Based on a suggestion by Dmitry Pankratov.
Task-number: QTBUG-27641
Change-Id: I1920f68ade44a996ea5c2ed691a87ff3e686f35a
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the outdated ones remain for backwards compatibility; some remain
unchanged.
Task-number: QTBUG-30083
Change-Id: Ia596b854d26b00fcb4f48df0da7ad893650ac1c8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
don't attempt to hand-craft a library export any more. instead, use the
configure system's built-in mechanism, and refer to it via QMAKE_USE.
this also allows us to rely on transitive dependencies in the autotest.
as a side effect, this makes the openssl-linked feature imply the
openssl one.
Change-Id: I5dd209b63bc8fbbc62852f6ffc472d4452ea2e68
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QNetworkSession's ctor has a race condition: it 1) connects signals/slots
and also 2) registers meta-types (but after these connects). Our users apparently
have a lot of per-thread QNAMs in multiple threads (and implicitly
many QNetworkSessions on different threads too). From error logs it appears
that while one thread tries to connect signals/slots and evaluates the types
of signal and slot arguments, another thread can register this type.
If the first thread extracted signal argument types, then the second
registered this type, we can end up in a 'type mismatch' error on the first
thread with seemingly the same types in a debug message (something like
"type mismatch A::Some <-> A::Some") - they have the same name, but one
has type() == 0 and another - some non-zero type().
Now we call qRegisterMetaType before connect.
Task-number: QTBUG-50901
Change-Id: Idbb9515573e174bbc5e5bf55dc3a7911a81646ea
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
There is no need in additional polling, because readyRead() signal of
the inner socket is directly connected to the slot which extracts the
datagrams. Moreover, calling _q_udpSocketReadNotification() from the
engine code might cause the spurious notifications both in the outer
and inner sockets.
Change-Id: Ibe75f5990e27b7460d628fa4a1ca4e64657e302c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Although it's permitted to specify the project name together with
a version number for \since, it's unnecessary for Qt classes and
functions.
This change also normalizes the version formatting: '<major>.<minor>'
Change-Id: Ie5a43662077d13c31e241bcde8a7a2849d27d330
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
We have an invalid pointer dereference in our callback.
Apple's docs are quite ambiguous, whatever we receive in our callback's
'client' parameter is our PACInfo, not clientContext's address.
That's what we pass to CFNetworkExecuteProxyAutoConfigurationURL:
"clientContext - A stream context containing a client info object and optionally
retain and release callbacks for that object."
This 'client info' is our PACInfo struct with 2 pointers.
Now in a callback, 'client':
"The client reference originally passed in the clientContext
parameter of the ..."
So apparently we should read this as "client info originally passed in ...."
Otherwise incorrect cast results in invalid pointer (apparently
the value of retain/release/copy pointers we carefully set to 0)
and a crash on dereference.
Task-number: QTBUG-56747
Change-Id: I89378f1582679638cd29a36c563e506d8f5af518
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
waitForWrite can emit a signal outside QLocalSocket and pipeWriter
could be deleted there.
Change-Id: Ic35ec6455bd05402fd38fb3e1b219aa4534a0ff6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This commit simplifies defaultParameters() to simply construct an empty
QSslDiffieHellmanParameters and assigning the DER-form of the DH parameters
to QSslDiffieHellmanParametersPrivate's derData field.
This creates a valid QSslDiffieHellmanParameters instance, but skips any
potentially expensive verification steps.
The previous implementation of defaultParameters() would use the public
fromEncoded() method to construct an instance of the default parameters.
This triggers a verification of the passed-in data, which can be expensive.
To ensure our defaultParameters() QSslDiffieHellmanParameters instance does
pass verification, this commit adds an autotest to verify that.
Fixes QTBUG-57815.
Change-Id: I6b1d9dbbfde526b232c319195ddbad42326be27c
Task-number: QTBUG-57815
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
qHash(QHostAddress) was added in Qt 5.0 (at least the version with uint seed = 0).
op==(QHostAddress::SpecialAddress, QHostAddress) was there since QHostAddress was
added before public history. Since QHostAddress does not have a \since, the I did
not supply one for op==, either.
Since the equality operator did not have unit-tests, added one.
Change-Id: I954a0df02464338f08a12ca58d4cc0ceb013e67a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
GCC 7 warns about implicit fall-throughs now.
Fix by adding the missing Q_FALLTHROUGH(), and, in one case, by
moving the existing suppressant into the correct position.
Change-Id: I7383f47e690b6334ef69c9df745c2205247ca7d0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
log a message in all unsuccessful exit paths.
Task-number: QTBUG-57217
Change-Id: I8b0f2685d327da583c3e42c8149327e05b2a66cc
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Because it was a function-level static, the QFactoryLoader was getting
destroyed out-of-sync with the bearer thread stopping. Under normal
conditions, the thread stopped first (~QApplication / ~QCoreApplication
via qAddPostRoutine), and the static got destroyed when the process
exited. However, if QApplication leaked or if the destruction order is
wonky (as seen in PyQt5), the thread could still be running when the
plugins were already unloaded.
With the loader a member variable, it gets destroyed when the thread
stops.
Note: in Qt 5.7, QFactoryLoader no longer unloads the plugins (since
commit 494376f980), so this crash cannot
happen in that version.
[ChangeLog][QtNetwork][Bearer management] Fixed a bug that could cause a
crash on application exit, depending on the order of destruction of the
QCoreApplication object and the QtDBus manager thread.
Task-number: QTBUG-56228
Task-number: QTBUG-52988
Change-Id: I33dc971f005a4848bb8ffffd147853376f82de2a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Err: Undocumented parameter 'enable' in QNetworkProxyFactory::setUseSystemConfiguration()
Err: no such parameter 'editable' in QComboBox::setCompleter()
Change-Id: Ib27b93cf74e97efd656eda1265003f33c6802005
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
QHostAddress allowed assignment from a QString, but the respective
constructor is explicit, and rightfully so. So it does not make
sense that the assignment operator is provided, because of the
asymmetry caused between
QHostAddress addr = funcReturningQString(); // ERROR
addr = funcReturningQString(); // OK (until now)
By the same token, since SpecialAddress is implicitly convertible
to QHostAddress, provide the missing assignment operator from that
enum.
Add tests, rewriting the _data() function to use the enum instead
of an int to pass SpecialAddress values, and to test !=, too.
Added setAddress(SpecialAddress), since a) it was missing and
b) to share code between the ctor and the assignment operator.
Change-Id: Ief64c493be13ada8c6968801d9ed083b267fa902
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Similar to the way datagrams are handled for udp sockets the worker now
takes care of tcp data. Thus we avoid race conditions which stopped data
processing. It could happen that data was read from the socket into the
buffer and before readyRead was emitted the buffer was completely read.
In this case readNotification is set to false and no new data is processed
afterwards.
Additionally the buffer was replaced by a vector of QByteArray. The buffer
kept growing and was never cleared (and there is no obvious way for
clearing the buffer), so that an overflow happened eventually.
pendingReadOperations (and its mutex) could be removed as well. There is
only one situation where they could clash and that's the initial read.
Having two members is preferred over having a list of operations and a
mutex.
Task-number: QTBUG-56438
Change-Id: Idbad58e47785996023748c310530892163f24594
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
We have a 'channel' object connected to a socket with Qt::DirectConnection.
QHttpNetworkConnectionPrivate in its dtor (note, it's a private object destroyed
after its 'q' - QHttpNetworkConnection - was destroyed) calls socket->close()
and this can end up in socket setting an error and emitting (for example, in
QSslSocket::transmit). The slot (QHttpNetworkConnectionChannel::_q_error) will
access the now-dead/non-existing connection then. So disconnect the channel
from the socket early, before closing the socket.
Task-number: QTBUG-54167
Change-Id: I3ed4ba4b00650c3a39e5c1f33aa786e47bfbbc57
Reviewed-by: Konstantin Tokarev <annulen@yandex.ru>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
It was phrased for an out-of-date version of Qt.
Adapt phrasing to be future-proof. Reflow text.
Change-Id: Ic026a7719ba6fb1de2830358a75cd6f30c5f8897
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They should be enabled/disabled through the configuration system.
Remove some unused defines, and move one define from qglobal.h to
a proper feature definition in Qt Gui.
Change-Id: Ie8d5bff9712ba745af60b42ceca3f0440bed2706
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We have:
...
auto networkSession = getNetworkSession();
...
getNetworkSession() can return non-null pointer even if
networkSessionStrongRef is null:
...
if (networkSessionStrongRef)
return networkSessionStrongRef;
return networkSessionWeakRef.toStrongRef();
....
We check the result:
if (networkSession) {
// here we disconnect signals
}
But we should use the same networkSession when disconnecting,
not start using networkSessionStrongRef suddenly, since it can
be null.
Task-number: QTBUG-57110
Change-Id: I96babb42c2182e741e6eabaf7d1abb88869861f4
Reviewed-by: Jesus Fernandez <jesus.fernandez@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Windows Information Protection is used for splitting corporate and
personal data, requiring connections to be established in a different
way instantiating ThreadNetworkContext.
Usage is enabled via the QT_WINRT_USE_THREAD_NETWORK_CONTEXT environment
variable.
Change-Id: I3aaa097b66fc616d42cd05a1e20bbcb004f6e467
Reviewed-by: James Tong
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We first hide identifier 'hr' and then later we check the one that was never
correctly initialized.
Task-number: QTBUG-57226
Change-Id: Ibbf1bb99aa752c2e4090caf4533dc5f5b71b5e41
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Fix compilation with topleveldomain, textodfwriter
and cssparser features disabled.
Change-Id: I3f061fb09eef36cd640256a46cf77dde85a54d3d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Commented its purpose and the guarded members for
readMutex.
Fixed places where guarded members were accessed without
using the mutex.
Use QMutexLocker instead of manually (un-)locking the
mutex.
Task-number: QTBUG-44357
Change-Id: I3049bb0df30f00659dc284c8e30ad7503c11e7c6
Reviewed-by: David Faure <david.faure@kdab.com>
At the point in time when the callback is called it is very
unlikely that another thread sets the state or error of
the socket engine. Other members (readBytes, bytesAvailable)
are protected by readMutex.
Change-Id: I76cf12fbc9019d1b42846c4b40e0cd1c06bbb220
Reviewed-by: David Faure <david.faure@kdab.com>
As the list is changed inside a native callback
(handleReadyRead) which can be run inside another
thread it has to be protected by a mutex.
Change-Id: I145a866a36a12b7ea9bfa9f99ad9f7add872a021
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Commented its purpose and the guarded members for
readMutex.
Fixed places where guarded members were accessed without
using the mutex.
Use QMutexLocker instead of manually (un-)locking the
mutex.
Task-number: QTBUG-44357
Change-Id: I0d46f9592d5a9d1b52e73df961785a6f6c9e80be
Reviewed-by: David Faure <david.faure@kdab.com>
Daiwei Li
Timur Pocheptsov
Ulf Hermann
Thiago Macieira
Edward Welbourne
Oswald Buddenhagen
Alex Trotsenko
Topi Reinio
Friedemann Kleint
Aleksei Timofeyev
Mikkel Krautz
Marc Mutz
André Klitzing
Liang Qi
Nico Vertriest
Oliver Wolff
Alexander Volkov
Lars Knoll
Maurice Kalinowski