In the case where we have pending data to write, calling flush() here
may cause the device to close immediately, if the pipe writer already
got a result of the last operation from the thread pool. In this
scenario, the device does not enter the 'Closing' state, which leads
the following code to unexpectedly fail on Windows
socket.write(...);
socket.disconnectFromServer();
QVERIFY(socket.waitForDisconnected());
Removing the call to flush() makes the behavior consistent with the
implementation on Unix.
Change-Id: Ic31fbc999be979c1e5befa8f132d9fb367f472ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
According to the documentation, calling abort() should immediately
reset the socket to its initial state. This includes:
- closing the file descriptor;
- closing the QLocalSocket as an I/O device;
- canceling a pending outgoing connection, if it exist;
- reseting 'serverName' string.
So, adding a call to close() resets the state entirely.
Pick-to: 6.1 6.2
Change-Id: I9c604b5187c6300b437d7aa4c2d06db03edacf21
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
These signals allow monitoring where in the HTTP1/HTTP2
flow a request is currently in.
Fixes: QTBUG-71698
Fixes: QTBUG-18766
Change-Id: Icc2fe435afc9f680fa7a76c32731e25fcdfeb4b4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The server's socket may not have been created yet, so use the server's signal
instead.
Switch to QCOMPARE to get better output.
Delete the extra checking for schannel, we don't support Windows 8 anymore.
Pick-to: 6.2
Change-Id: Icd310c32939cb577c9f3438789f667aa0a3a4d85
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If the file already existed we simply removed the old one without
adjusting the size. So use the removeFile() function which takes care of
that.
Additionally, if the current size was non-null we previously increased
the size (presumably meant to be temporarily but wasn't) and called
expire() which would either:
1. not do anything and return currentCacheSize, if it was not greater
than the max size. This would mean that the size of the file would be
counted twice.
or,
2. discard currentCacheSize, measure the size of the items, and then
remove some items if the total size surpassed the max cache size
Neither of those branches need us to (temporarily) increase
currentCacheSize. It also doesn't attain the (presumed) goal of trying
to keep below the max cache size after having added the new item.
Fixes: QTBUG-95009
Pick-to: 6.2 6.1 5.15
Change-Id: I2b5b13ff473a7aa8169cf2aecfea783c97f2d09a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Qt has a hardcoded backlog value of 50,
this allows for applications to tune this
value. Modern kernels have the SYN cookie
feature that reduces pressure from an
flood attack, the backlog setting however
is then a queue for most likely real
completed (SYN/ACK) connections hence, it's
easy to get clients connections dropped
with this very small limit.
[ChangeLog][QtNetwork][QTcpServer] Added
QTcpServer::setListenBacklog() to be able
to have control over the listen backlog feature.
Change-Id: I1c78af6d99e012591e214b7e09fa85c485880d48
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Both readChannelFinished() and disconnected() signals should be emitted
after closing the pipe. Otherwise, these signals do not correspond to
the state of the socket and may even be resent, if a slot connected to
one of these signals processes events.
[ChangeLog][QtNetwork][Important Behavior Changes] QLocalSocket on
Windows now emits both readChannelFinished() and disconnected() signals
after closing the pipe and emitting stateChanged(UnconnectedState),
which is consistent with the behavior on Unix.
Pick-to: 6.2
Change-Id: I1cc551b7897fdba3cec1fd6705f5396790818c7d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The ${QT_SOURCE_TREE}/src/network include paths of several tests are
apparently not needed anymore. Remove those.
tst_qfilesystementry and tst_qfreelist are the only tests that actually
need to reference files in qtbase's source tree. Simply use the paths
relative to the project file.
Task-number: QTBUG-88090
Change-Id: Ic6f341e001338c1b07dce6e58316245bc9560c5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The base implementation discards the data by reading into a dummy
buffer, which is slower than necessary.
Change-Id: Iabf0c4a25746af6cac5b61d7bda66d89501c808c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
QIODevice::readLine() can also return partial lines, which was not
properly documented. Add an autotest for QLocalSocket to illustrate
and test this behavior.
Pick-to: 6.2
Change-Id: Ia2c1c438cc68d2672d34881e11fdf7837232f3b4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
With MSVC it tries to link with the function in the scope qt::tst_QDtls::*
where it is not found
Pick-to: 6.2
Change-Id: If83a9f69c7b3834248569f6bdf203f5442693080
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
To (set)decompressedSafetyCheckThreshold, as suggested on the API review.
Task-number: QTBUG-94407
Change-Id: Iffc52691022939ae46703de8a0416355487b716f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Fixes compiler warnings:
warning: implicit capture of ‘this’ via ‘[=]’ is deprecated in C++20 [-Wdeprecated]
Change-Id: Ia7cf50f491e92f39162c69afb2a8320afedba056
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
For flush() it's not clear what they wanted to test.
isEncrypted() is tested indirectly in many of the other tests.
Change-Id: Id6dfecbb25b7bba8f1a99518fd9c9e06280aaa9f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It needs to be checked at runtime to know if the current backend
supports it
Pick-to: 6.2
Change-Id: I0998309149b109e2075a008b2b8d8115fa3688cc
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
With MSVC the current way we mark it (potentially) unused ends up with a
warning:
warning C4551: function call missing argument list
We require c++17 core language support so let's use [[maybe_unused]]
instead.
Pick-to: 6.2
Change-Id: I125986b729cb7cd540901702a47365f0491e7887
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As per the best practice laid forth in RFC-8996.
TLS 1.2 was recommended from 2008 until TLS 1.3 was released in 2018.
[ChangeLog][QtNetwork][QSslSocket] TLS 1.0, 1.1 and DTLS 1.0 are now
deprecated, as recommended by RFC-8996.
Fixes: QTBUG-92880
Change-Id: I90cebcfb07cfce623af7ac9f2b66ce9d02586b54
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Since we're no longer connected, much less encrypted.
Was done in schannel backend, but not in ST or OpenSSL
Pick-to: 6.2
Change-Id: Ia49387be0088f899a0c89091f7e468dba1c0eee6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
With the recent change, 'system' headers gone: not in the test code anymore,
so, for example OPENSSL_VERSION_NUMBER is undefined, making the test
to select a wrong code-path - 'h2c', instead of encrypted h2.
Pick-to: 6.2
Pick-to: 6.1
Change-Id: I3b201e21fac56875c9045c7463e2ae69af4c6470
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Previously, it went direct to QTestResults::addFailure() without going
via the checking for expected failure. Add QTestResults::fail() to
take care of this checking, as for verify() and compare().
Tidied up the code implementing expected failure and QFAIL(), while I
was about it. Adjusted an existing test to verify that expecting a
QFAIL() works, by using QFAIL() instead of QVERIFY(false).
Remove the QVERIFY(false) whose comment brought this to my attention.
[ChangeLog][QtTestLib][QFAIL] QEXPECT_FAIL() now correctly anticipates
a subsequent QFAIL(). Previously QFAIL() counted as a fail regardless.
Change-Id: Icc28cf70e5ff3006363791ea03aa01f2f591eb71
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Rather than when the data is received. Source compatibility is
achieved through double-decompressing the data. This lets us know
how many bytes are available just as before but without having the
uncompressed data left in memory.
Fixes: QTBUG-83269
Change-Id: I352bd09581614c582e4628243e2a0e895ba4946b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
For auto-tests that were temporarily disabled. Similar to
network-settings.h, header-only stuff.
Fixes: QTBUG-92866
Fixes: QTBUG-92877
Change-Id: I15b5c0b41f0d8bfe59b09c844884ff6d99e6d41a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The error that the actual runtime will encounter, and not the one that compile-time
ifdefs will (potentially) erroneously select.
Change-Id: I8ef4c34bcb8b3e568bc39f8c8ea6bfb7732f9e27
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Make it return bool since the TriState was really only used signify that
the property was unsupported but there is already a separate way to
check if it's supported. More importantly there is no different set of
actions available to a user if they're in the Unknown or False state.
Because of the change to bool, we also rename the property to have an
'is'-prefix.
Change-Id: Iaaaad5ac31e663c36e00223bf5b0e719f412fc69
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Instead of relying on some string comparisons and the current knowledge
of which backend supports DTLS, use the proper API we already have in
place to test if a particular class is supported by the active backend.
Change-Id: I58ca0f7b7fcef68ec375cd64b83e51d4335817da
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch adds the API, with no supporting backends
Task-number: QTBUG-93848
Change-Id: I50454717f928819e1b990df91872675e842f9987
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It's possible that Qt is built with OpenSSL and some other backend.
The ifdefs generated are not mutually exclusive anymore, as it was
in the past. So tests should rely on the actual backend they have
working at runtime.
In the process of fixing the auto-tests, modernized feature #if-ery and
some associated compilation issues.
Fixes: QTBUG-92875
Change-Id: I2be1b924d506fd36dc4e2c6c9158b5023ff87f32
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QNetworkInterface reports as up and running an interface,
seemingly having a valid IP address which actually has
not IPv4/IPv6 configured at all (this is what getifaddrs
gives us).
Change-Id: I5808d5dfdbc54004a1e02b791917e9b2ba62905f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
For some reason the test case was (no longer?) detected by moc
Change-Id: I20f20de76479f7d9db43fae985cefe0869a7e203
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
To see if a certain method is supported. To be used in an upcoming patch.
Change-Id: I1a5c2f655585331820701bb54f6991b4aba38273
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The BASE argument of qt_add_resources now denotes the root point of the
alias of the file. Before, BASE was merely prepended to every file that
got passed to qt_add_resources.
Old behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "images/button.png")
Alias is "../shared/images/button.png", and pro2cmake generated
QT_RESOURCE_ALIAS assignments to fix this.
New behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "../shared/images/button.png")
The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment
is needed.
The new behavior is in effect for user projects and for Qt repositories
that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be
ported one by one to this new behavior. Then the old code path can be
removed.
Pick-to: 6.1
Task-number: QTBUG-86726
Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Already blacklisted on the other linux versions, but is failing on
SLES now in 5.15
Pick-to: 6.1 5.15
Change-Id: I267908adf94ede51e5520aa2cb806b394fb0438e
Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And use this in the authenticationRequired test.
Pick-to: 6.1 6.0 5.15
Change-Id: I18e991eb67168214c2c4f829afaca5018568e989
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
With Qt 6 we made HTTP/2 default, which exposed missing handling of
401 Unauthorized (and 407 Proxy Authentication Required).
In HTTP/1.* we would handle this after the response had finished, while
handling the status code. For h2 this path isn't used since it is
heavily reliant on the structure we have for HTTP/1.* (one request per
channel). So we must handle the status code and header directly.
Having that part fixed exposed another issue - when resetting/rewinding
uploaded data we were not resetting the 'totallyUploadedData' counter in
the reply (this, in turn, exposed another small issue). Because of that
we did not actually send any data on the retry, only sending the
content-length followed by no data.
Finally, the small issue mentioned in the previous paragraph was how we
check if we have uploaded all our data. It was only checking if the
byte-device was atEnd(), which it was. But only because it had not yet
prepared any data for us.
Fixes: QTBUG-91284
Pick-to: 6.1 6.0 5.15
Change-Id: I798d105b02688b18a02897cc476f19f57a47f98f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The qt_ForceTlsSecurityLevel symbol is not defined if SSL is not configured,
so don't use it in the QNetworkReply test if it's not.
Change-Id: Id3110a1997fea1648b48bfc411e90e7efe306678
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
All TLS (and non-TLS) backends that QSsl classes rely
on are now in plugins/tls (as openssl, securetransport,
schannel and certonly plugins).
For now, I have to disable some tests that were using OpenSSL
calls - this to be refactored/re-thought. These include:
qsslsocket auto-test (test-case where we work with private keys),
qsslkey auto-test (similar to qsslsocket - test-case working with
keys using OpenSSL calls).
qasn1element moved to plugins too, so its auto-test have to
be re-thought.
Since now we can have more than one working TLS-backend on a given
platform, the presence of OpenSSL also means I force this backend
as active before running tests, to make sure features implemented
only in OpenSSL-backend are tested.
OCSP auto test is disabled for now, since it heavily relies on
OpenSSL symbols (to be refactored).
[ChangeLog][QtNetwork][QSslSocket] QSslSocket by default prefers 'openssl' backend
if it is available.
[ChangeLog][QtNetwork][QSslSocket] TLS-backends are not mutually exclusive anymore,
depending on a platform, more than one TLS backend can be built. E.g., configuring
Qt with -openssl does not prevent SecureTransport or Schannel plugin from being
built.
Fixes: QTBUG-91928
Change-Id: I4c05e32f10179066bee3a518bdfdd6c4b15320c3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As suggested in the API review.
Amends 37bd7b5733
Pick-to: 6.1 6.1.0
Change-Id: Ic3e8567f349568dc3b4dbf79be27c304b39480cf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
On Windows, on exit, the backend will deref (and then implicitly start
deletion of) a COM object. This object tries to communicate with an
object in another thread, though it seems this other thread quits before
the main thread in _most_ cases.
To get around this we move the deletion to earlier in the program. While
this is only reported as a Windows issue it makes for more consistent
behavior if all platforms behave the same.
Document and test that recreation of QNI works as expected after the
destruction (and recreation) of QCoreApplication.
Amends: 0875626e22
Fixes: QTBUG-92568
Pick-to: 6.1 6.1.0
Change-Id: Iffc07f38673019aa059efd4d64d2ad706a03f6fe
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
It was more complex than needed in a few places.
Change-Id: I0609423f82420f72c65637cf398ccd7694ee85e5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The 'pipeBroken' flag must be updated before emitting the readyRead()
signal to avoid deadlock of waitForReadyRead() inside slot connected
to readyRead().
Change-Id: Ie393fdd594c6691da6609ea18307589b7157c624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Takes advantage of Linux's and Android's support for abstract namespace
when binding sockets, which is independent of the filesystem (see man
entry for unix domain sockets).
To make QLocalServer and QLocalSocket use an abstract socket address,
one needs to set the socket options to QLocalServer::AbstractNamespaceOption.
Fixes: QTBUG-16090
Change-Id: Ia9f9c9cc1ac5c28f9d44b0a48d854a7cfbd39b11
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This can only be completed in Qt 7, due to BC guarantees. I've only
updated the source code for QHostAddress and its unit test and even then
I did not touch the documentation. This needs to be completed in Qt 7.0
Change-Id: I26b8286f61534f88b649fffd166b695882f8f3b5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
All backend-specific code is now separated and removed
from QSslSocket(Private) code. The original code is mostly
preserved to avoid (as much as possible) regressions (and
to simplify code-review).
Fixes: QTBUG-91173
Task-number: QTBUG-65922
Change-Id: I3ac4ba35d952162c8d6dc62d747cbd62dca0ef78
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 9391ba55149336c395b866b24dc9b844334d50da)
Renamed the private part of the namespace to QTlsPrivate.
Fixes: QTBUG-91531
Change-Id: Id2d9c458d8d958b35e437eee42889177dad0a7a7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit e4efa00c72c7011f4e5c27722c2a522b30274610)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is to avoid false positives.
By default files are large if uncompressed size > 10 MB. Only configurable internally.
Also add auto tests.
Task-number: QTBUG-91392
Pick-to: 6.0 6.1
Change-Id: I32258cb7c957f2a23a05157ba4ed5c0af2ba585e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's a bit weird to calculate timeout in milliseconds and then pass
it as number of seconds ...
Pick-to: 6.1 5.15
Change-Id: I1127163ea06e49ac1b53eea6f60ee8590319bfa1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When a foreign event loop that does not enter an alertable wait state
is running (which is also the case when a native dialog window is
modal), pipe handlers would freeze temporarily due to their APC
callbacks not being invoked.
We address this problem by moving the I/O callbacks to the Windows
thread pool, and only posting completion events to the main loop
from there. That makes the actual I/O completely independent from
any main loop, while the signal delivery works also with foreign
loops (because Qt event delivery uses Windows messages, which foreign
loops typically handle correctly).
As a nice side effect, performance (and in particular scalability)
is improved.
Several other approaches have been tried:
1) Using QWinEventNotifier was about a quarter slower and scaled much
worse. Additionally, it also required a rather egregious hack to
handle the (pathological) case of a single thread talking to both
ends of a QLocalSocket synchronously.
2) Queuing APCs from the thread pool to the main thread and also
posting wake-up events to its event loop, and handling I/O on the
main thread; this performed roughly like this solution, but scaled
half as well, and the separate wake-up path was still deemed hacky.
3) Only posting wake-up events to the main thread from the thread pool,
and still handling I/O on the main thread; this still performed
comparably to 2), and the pathological case was not handled at all.
4) Using this approach for reads and that of 3) for writes was slightly
faster with big amounts of data, but scaled slightly worse, and the
diverging implementations were deemed not desirable.
Fixes: QTBUG-64443
Change-Id: I66443c3021d6ba98639a214c3e768be97d2cf14b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This patch marks some functions "override" to silence the corresponding
warning.
Change-Id: I88ccc5fa7521ecccc84a6cba9f06ea185cc5679e
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The idea is to have QSslKey(Private) backend-neutral and hide
all library-specific code inside plugins.
Fixes: QTBUG-90953
Task-number: QTBUG-65922
Change-Id: I2eeee3b2b72c78c2e24f2fb914abce3caa913be8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
(cherry picked from commit 0352cf8e1bf57615b9faf3f6f383896444e762ac)
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The emulation detection has been usable only on qtbase tests, move it to
QTest so that it can be used in other modules as well.
Pick-to: 6.1
Change-Id: I4b2321b7856414d7b1cfd5e6b1405a633c6bb878
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QTlsBackend is a factory itself - it creates TLS/X509 objects. Having
an intermediary between Factory->Backend->TLS primitive does not look
very natural thus let's squash the first two parts. Backend is a factory
creating TLS primitives, but its static functions also provide information
about backends availablei and give access to those backends.
Fixes: QTBUG-90606
Task-number: QTBUG-65922
Change-Id: I8409d81fd11fb46e6ab4465b4937a7680a8c2447
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Read/write/notify properties, 3 out of 5 defined in this class.
Task-number: QTBUG-85520
Change-Id: Ic6c74f90a2fa3c71d71cf9a5d557f1b6fc489d35
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Fetched from the authoritative source, verified the content matches
that of the current master revision in the github repository.
Amend one cookie jar test to find the last group in the last chunk
correctly - each group arises from a non-empty hsah-table entry, but
the last few hash-table entries may be empty, in which case the last
group isn't just before the last index, it's earlier by the number of
empty hash table entries. In the process, amend this test and the
related test of the end of the first chunk to iterate all the entries
in the group (in the present version, as it happens, each end-group
has just one entry, but that may vary).
Task-number: QTBUG-90214
Pick-to: 6.0 5.15
Change-Id: I6da365a6ca558124f8275e392735071dc77e04bb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is an abstraction for TLS backend and its factory, preparing to transition
to plugin-based design.
Task-number: QTBUG-65922
Change-Id: Ibe810e77fd1b715a6bea66cd3f44312b015ac274
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This API gives the names of available backends and provides a basic
information about features/protocols supported by those backends.
Also, it has the 'loadBackend' functions which allow to select
a particular backend (which are becoming plugins).
At the moment, the implementation is still 'hardcoded', the
follow-up patch will allow to select different backends in runtime.
Task-number: QTBUG-65922
Change-Id: I05877de9c02857594e76b24d52e7578bdb01df69
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The plugins are meant to indicate what they do support, meaning users of
QNetworkInformation can choose to not care about which plugin is used
and rather just request what they want.
Task-number: QTBUG-86966
Change-Id: Ie130e1791250ec2a4470e3ba7081d982654af06c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
SecureTransport does not allow deprecated digest algorithms, and
(depending on ST version) it may or may not accept our server's
certificate.
Funnily enough, they 'fluctuate' between versions again and again.
Fixes: QTBUG-89922
Change-Id: Ie5fbfca316806bd5000ce2d128b81b718bb36624
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
SIOCGIFNAME is now supported on QEMU.
This reverts commit 42b3ed763f.
Change-Id: I79caa371dc798464ab76851d2ea3189ec9eb0c57
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apparently some library definitions went overboard, link them directly.
Pick-to: 6.0
Change-Id: I009737f7e3edff5619241b700a627dc4e25e6018
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Looking at grafana it rarely fails in dev so unblacklisting it.
Though it is a little more flaky after switching to http 2 by default
because then we only have one channel and more requests end up queued in
the same channel, which will get errored out when the server
disconnects.
Task-number: QTBUG-88943
Change-Id: If5d6335864ce6bbc35f519b2c6d7068e4181afd2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
headFromHttp hasn't been flaky since 5.14 times according to grafana,
does not fail locally.
Same situation with ioHttpRedirect as above.
ioHttpRedirectMultipartPost has not failed on Windows since october
2019, assumed stable now.
backgroundRequestInterruption no longer exists.
ioPostToHttpFromSocket would fail in debug MSVC builds but was
fixed in 710886fbdd.
Task-number: QTBUG-88943
Change-Id: Ida640179ef15a3452291745e4e94a71a385f57ae
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
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>
It's not _wrong_ to time out when connecting to something unreachable
(it's just a different way of handling it) so we shouldn't fail when
this happens either.
In local testing (windows) it times out after 8 seconds, so bump
the timer to 10 seconds. On systems where it's faster there'll be
no difference as long as things don't go wrong.
Pick-to: 6.0
Fixes: QTBUG-89089
Change-Id: I8437cf8e4fbecedea2391ed87fdce1213085b964
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Which contains a lot of 'macos'/'osx' black-listed auto-tests. They
mostly fail with SecureTransport (on BigSur) because SecTrustEvaluate()
does not like our old certificate. Instead, since SecureTransport
is deprecated anyway and we are not planning to develop it in future,
skip the related auto-test depending on QT_CONFIG(securetransport).
Task-number: QTBUG-88943
Change-Id: I5f6cb7b2d0ea15c445603c1ff3e1700f123c28d1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It was blacklisted due to the issue there. The issue is resolved, but
the blacklist stayed.
Task-number: QTBUG-88943
Change-Id: I7d9a660a17c1463dd8b654752ed5787fe5f5af24
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The requests will remove themselves once they get deleted
but since the deletion is done through a _queued_ invokeMethod
to 'deleteLater' we will call
QHttpNetworkConnection::_q_startNextRequest first which may
end up starting a reconnect of the TCP socket which we had the error on.
In this specific instance it manifested as a race condition where we
either don't get a proxyAuthorizationRequired signal at all (it was
emitted while we didn't have any valid replies), or we get the signal
emitted too late and it gets emitted on whatever the next reply was.
Task-number: QTBUG-88417
Pick-to: 5.15 6.0
Change-Id: If3f8ececc5550f1868c90124559cb8e3029646d8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Currently untested
The socks case is odd: after accepting the first connection it shows as
unconnected. Details as for why is unknown, out of scope of adding this
test.
Pick-to: 6.0
Change-Id: I0e7658f23b89f3af8db379b001ee33a844f3bec4
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
And also, reduce the utter sloppiness, weirdness of the test and
make it more a test and not a joke. Since the test itself depends
on !QT_NO_SSL, why bother building and running its main, to create
a useless tst_QSslError and do nothing then? Exclude test from
no-ssl build.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I67879b0de036cbc8c2f75a18f4cf94e6c43c5af0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QSslCertificate::verify() has an undocumented and not very desirable property -
on some platorms it updates the default configuration, which can be surprising.
For example, we deprecated QSslSocket::setDefaultCaCertificates() and recommend
using QSslConfiguration::defaultConfiguration(), QSslConfiguration::setDefaultConfiguration(),
and QSslConfiguration::setCaCertificates(). If an application does this to select
CA roots it trusts explicitly, and then for some reason is calling verify, the
application can have its QSslSockets successfully connecting to a host, whose
root was not trusted by the application. Also, on Windows, defaultCaCertificates()
include system roots already, no need to have them twice.
[ChangeLog][QtCore][QtNetwork] QSslSocket::verify - do not change the default configuration
Pick-to: 5.15
Pick-to: 6.0
Pick-to: 6.0.0
Fixes: QTBUG-88639
Change-Id: I1cd40b259d0a6dcd15c78d1e7c027ff10859595c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And extend an auto-test for this. When a cookie verification mechanism is
enabled, and verifier, indeed, verifies that some datagram is a 'Client Hello'
message with a proper cookie attached, we start a real DTLS handshake creating a
QDtls object and calling 'doHandshake'. In case cookie verification
was enabled, we need parameters from the verifier (it's a crypto-strong
'number' and hash algorithm) to 'lock and load' the TLS state machine in
a freshly created TLS session object. This code path previously was only
tested manually and was found by LCOV as untested.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: Ieacb8c989997999ea10e15bda6ae106a0338b698
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
And do not run the test with QSslSocket::supportsSsl() returns false -
this may mean unresolved symbols and thus missing functionality,
like i2d_X509 etc. This also makes cases more like other, that already
had those checks.
Fixes: QTBUG-87386
Change-Id: If4e9a650ca325b6f70956f532891a4c1d50465c0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Some code-paths were never executed by auto-test, thus giving us LCOV's
diagnostic. Extend existing tests and add new ones.
Pick-to: 5.15
Change-Id: I648747547f0525a482216b1e1972fcc698c73f65
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By extending (a bit) an auto-test to cover paths found by LCOV. All of them
is just to trigger the code that checks input parameters.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I62f9a9045038ff8d123fd1396f4bfd85e75c6d8f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By adding auto-tests that were missing/not triggering the paths found
by LCOV.
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I472f59e8e7292786c80d7c8dcebde53a2982e1ec
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By simply extending the basic test to trigger qHash, isEqual and
a bunch of getters.
Pick-to: 6.0
Pick-to: 5.15
Change-Id: Ib1d88fc6d2ad623743cea77ac286ae6ac819dfd1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
tst_qsslcipher was quite useless - now we test that default constructed
QSslCipher reports expected values. Test the non-default from the
different auto-test, where we are sure we have really useful
ciphersuites (with different parameters obtained from a TLS backend,
where it's possible).
Pick-to: 6.0
Pick-to: 5.15
Change-Id: Iff14a0580fed889cf9e0873bee01d968773626db
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
... instead of failing the test. On Ubuntu 20.04 when calling
'connect' with 0.0.0.1 we get EINPROGRESS and nothing else,
since our own internal timer has 30 s. timeout, the event loop
in the test stops before this and no socket error detected yet.
Handle such situation without failing a test.
Fixes: QTBUG-88042
Change-Id: Id6add27fcf9bbbe5fbf83a193652edf08fbad8d6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This reverts commit ee122077b0.
Reason for revert: This causes QProcess::readAll() to sometimes
return nothing after the process has ended.
Fixes: QTBUG-88624
Change-Id: I34fa27ae7fb38cc7c3a1e8eb2fdae2a5775584c2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
(cherry picked from commit 23100ee61e33680d20f934dcbc96b57e8da29bf9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When a foreign event loop that does not enter an alertable wait state
is running (which is also the case when a native dialog window is
modal), pipe handlers would freeze temporarily due to their APC
callbacks not being invoked.
We address this problem by moving the I/O callbacks to the Windows
thread pool, and only posting completion events to the main loop
from there. That makes the actual I/O completely independent from
any main loop, while the signal delivery works also with foreign
loops (because Qt event delivery uses Windows messages, which foreign
loops typically handle correctly).
As a nice side effect, performance (and in particular scalability)
is improved.
Several other approaches have been tried:
1) Using QWinEventNotifier was about a quarter slower and scaled much
worse. Additionally, it also required a rather egregious hack to
handle the (pathological) case of a single thread talking to both
ends of a QLocalSocket synchronously.
2) Queuing APCs from the thread pool to the main thread and also
posting wake-up events to its event loop, and handling I/O on the
main thread; this performed roughly like this solution , but scaled
half as well, and the separate wake-up path was still deemed hacky.
3) Only posting wake-up events to the main thread from the thread pool,
and still handling I/O on the main thread; this still performed
comparably to 2), and the pathological case was not handled at all.
4) Using this approach for reads and that of 3) for writes was slightly
faster with big amounts of data, but scaled slightly worse, and the
diverging implementations were deemed not desirable.
Fixes: QTBUG-64443
Change-Id: I1cd87c07db39f3b46a2683ce236d7eb67b5be549
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The test authenticationCacheAfterCancel was the only one to fail
in recent COIN runs. This patch blacklists it on Ubuntu 20.04.
Task-number: QTBUG-88417
Change-Id: Idc85499da82336d291d9a90ecb941810a0e6c935
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
