fix the bloody test for good - the idea to have a shared QNAM (shared
by test cases in this test) was somewhat wrong to start with.
Fixes: QTBUG-77053
Change-Id: I5755e96ec988e2dd546f527f3f902fc43914b0b7
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
This reverts commit 9a25d27b9d58316dee5d2305135d2d74ad5d51e7.
The QSKIP is no longer needed as the imap server's certificate
was updated
Task-number: QTBUG-76610
Change-Id: I1007ce50d6f7f6258fdeb8894c66678a660b03ca
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>
QSslSocket (OpenSSL backend) does not use mutex/locks during
a handshake, so we re-enable previously skipped tests.
This reverts commit 8c87a1402c.
Change-Id: I994b085f016f0eb18b3ba439a7041ea08cd3577b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In this threaded setup the server can sometimes have the data before it
calls "waitForReadyRead", what happens then is that we fail the wait and
as a result the test fails overall.
Let's check if we actually got some data after all and then continue if
we did. Since both the client and the server currently wait the same
amount of time (2s) the max timeout for the client was increased by
0.5s so it has some time to notice that the server got the message.
Change-Id: Ib5915958853413047aa5a7574712585bcae28f79
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit e79b1dcdf5)
Reviewed-by: Simo Fält <simo.falt@qt.io>
(cherry picked from commit d53b8b77bc)
Change-Id: I2f6ffb8e0a9b4d591edb6925e48baffcefc14511
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
If this callback is not set then OpenSSL will call the callback
used for <= TLS 1.2 unconditionally when connecting. If using PSK it
will call it again later once the preshared key is needed.
We don't currently handle the TLSv1.3 PSK, but we definitely should.
But for now we can work around it - when psk_use_session_callback is
called we simply change the PSK callback to a dummy function whose only
purpose is to restore the old callback.
This is mostly done to keep behavior the same as it is now for users
(and to keep our tests running).
Later we can add a new signal and handle this new feature properly.
Reviewed-by: Simo Fält <simo.falt@qt.io>
(cherry picked from commit d8efc8d718)
Task-number: QTBUG-67463
Change-Id: I4aca4ae73ec4be7c4f82a85e8864de103f35a834
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We use global object to store errors found by q_X509Callback.
Thus, we also use a lock/mutex. It would appear all tests
involving in-process server and QNAM are prone to intermittent
failures on our Windows VMs - it's always about timeouts due
to the client socket (QNAM) locking and the server socket blocking
main thread while trying to acquire the same lock.
The real fix is to re-write our verification callback so that
it does not need locking/does not block the main and 'http'
threads as a result. But such change is too dangerous for
5.13.0 so we instead have a somewhat handicapped/reduced
test on Windows.
The fixed QSSlSocket will go into 5.13.
Task-number: QTBUG-76157
Change-Id: Ia54701bcb3f6f079a69e52c8904ac3efcee4a787
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
to test different h2 modes: "h2c" (clear text with protocol upgrade),
"h2" (encrypted, negotiating via ALPN extension), "h2-direct" (encrypted,
no ALPN), "h2c-direct" (plain text, no protocol upgrade). This patch-set
is an amendment to the recent fix in the protocol handler where we were
crashing in "h2c-direct" mode.
Change-Id: I3ff5ed1396a59b72b59a95f927d404ccd202d0b8
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Hardcoding IP addresses and their respective DNS records is fragile.
We care about Qt producing the same result as other DNS querying tools,
so testing that instead.
Running a python script for this is easiest, and assumed to be quite
reliable.
In case where python fails/is not present, fall back to nslookup.
That tool is available on Linux, macOS, and Windows, although the
output it produces varies. This change implements very basic
line-parsing that can interpret the various results encountered
during testing on those platforms.
This also reverts commit bbaceff253fae13d8e56691bc9de7e1981db5118,
which blacklisted the tests that failed due to changes in DNS
records.
Use the opportunity to replace usage of gitorious.org.
Change-Id: I967de226bd603c805df7fe3ed4e871d92d2d0750
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The DNS entry for the host has changed, dig answers with dns.google,
not with google-public-dns-a.google.com. While developing a proper
fix to the test, blacklisting this particular lookup allows
integrations to pass in the meantime.
Change-Id: Id37da6b24554803bf4e2c84be5b949ded40566e8
Reviewed-by: Kari Oikarinen <kari.oikarinen@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
It is constantly passing according to grafana.
Change-Id: I4953cd54e27adde8dad79e9a0f025960802e6c7a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
In the QNetworkAccessManager machinery we would treat "no-cache" as if
it meant "don't cache" while in reality it means "don't return these
cached elements without making sure they're up-to-date"
At the same time as this change is made let's add test data for
"no-store", which replaces the "no-cache" test data.
Fixes: QTBUG-71896
Change-Id: Ieda98f3982884ccc839cac2420c777968c786f6e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
If this callback is not set then OpenSSL will call the callback
used for <= TLS 1.2 unconditionally when connecting. If using PSK it
will call it again later once the preshared key is needed.
We don't currently handle the TLSv1.3 PSK, but we definitely should.
But for now we can work around it - when psk_use_session_callback is
called we simply change the PSK callback to a dummy function whose only
purpose is to restore the old callback.
This is mostly done to keep behavior the same as it is now for users
(and to keep our tests running).
Later we can add a new signal and handle this new feature properly.
Task-number: QTBUG-67463
Change-Id: I4aca4ae73ec4be7c4f82a85e8864de103f35a834
Reviewed-by: Simo Fält <simo.falt@qt.io>
In this threaded setup the server can sometimes have the data before it
calls "waitForReadyRead", what happens then is that we fail the wait and
as a result the test fails overall.
Let's check if we actually got some data after all and then continue if
we did. Since both the client and the server currently wait the same
amount of time (2s) the max timeout for the client was increased by
0.5s so it has some time to notice that the server got the message.
Change-Id: Ib5915958853413047aa5a7574712585bcae28f79
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit e79b1dcdf5)
Reviewed-by: Simo Fält <simo.falt@qt.io>
We use global object to store errors found by q_X509Callback.
Thus, we also use a lock/mutex. It would appear all tests
involving in-process server and QNAM are prone to intermittent
failures on our Windows VMs - it's always about timeouts due
to the client socket (QNAM) locking and the server socket blocking
main thread while trying to acquire the same lock.
The real fix is to get rid of global variable/locking, we'll
have it later (quite a change and requires a lot of accuracy).
Task-number: QTBUG-76247
Change-Id: Iffc90d9e16783f17f62e836e01c35f22681bdd39
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 91ab70d17f)
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
Fix test for systems that do not resolve their hostname to localhost.
Not using name resolution also makes the test more robust.
Change-Id: I558b9a975b9021536709db87fbf6a3b314f7ca79
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previous blacklisting 5c4e5032b5 only
covered RHEL 6.6 and RHEL 7.4. The problem however exists in all
6.x and 7.x distros as they have the same openssl.
This however leaves us the problem with future RHEL 8. This will
keep blacklisting these tests there as well. We need a way to blacklist
versions with a wildcard so that we could say RHEL-7.*
Task-number: QTBUG-46203
Change-Id: I2cc52ba2eac949214ecaa02e19d9e623d5befc49
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
'accept' breaks the order, making the static table unsorted and thus
std::lower_bound cannot find it and we always index it in a dynamic
table. Also, make this static table accessible to auto-test.
Plus fix some warnings quite annoyingly visible in qt-creator.
Fixes: QTBUG-74161
Change-Id: I47410f2ef974ac92797c9804aa55cb5c36a436c4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It fails on CI (Windows 10). Given our qabstractsocket disables
read notifications/stops emitting readyRead if it already has pending data
(unbuffered, aka UDP socket type) - make sure we do not suffer from this.
The change does not affect the test's logic (unless the logic was to fail),
it just makes it more fail-proof.
Change-Id: I6c9b7ded20478f675260872a2a7032b4f356f197
Fixes: QTBUG-73884
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
1. Fix erroneous logic, which was triggered in 'h2' mode (non-TLS connection)
- after the initial protocol upgrade/POST request was handled, the server
(on Windows specifically) was erroneously handling upcoming DATA frames by replying
with another redirect response.
2. Make the test less heavy by sending 1 MB of Qt::Uninitialize instead of 10 MB
- theoretically this could cause a timeout before the redirected request finished
successfully.
Task-number: QTBUG-73873
Change-Id: I961e0a5f50252988edd46d0e73baf96ee22eef3f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
[ChangeLog][qmake] A new feature "cmdline" was added that implies
"CONFIG += console" and "CONFIG -= app_bundle".
Task-number: QTBUG-27079
Change-Id: I6e52b07c9341c904bb1424fc717057432f9360e1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
[ChangeLog][QtNetwork][SSL] The Schannel backend now supports ALPN and
thus HTTP/2.
Change-Id: I1819a936ec3c9e0118b9dad12681f791262d4db2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
On Windows and macOS, the containers are deployed into a virtual
machine using the host network. All the containers share the same
hostname (qt-test-server), and they are connected to the same network
domain (local).
When running test in such platforms, use the single-name SSL certificate
(qt-test-server.local) for SSL related tests.
Change-Id: Idf33e01e8dd8814510d848b87b59b5fc0edc903e
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
For some reason behavior of SecureTransport has changed from 10.12 to 10.13
and then to 10.14. On 10.13 SecureTransport fails upon receiving the server's
certificate with 'Unrecoverable error', before we can do a manual verification
and accept the certificate as trusted. Analysis of available source code
shows that they, apparently, do not like MD5 hash which our server is using.
Until certificate is updated on the server or we switch completely to
the Docker-based solution we have to BLACKLIST tests that connect to our
current network test-server. Oddly enough, on 10.14 SecureTransport is
less mean.
Task-number: QTBUG-69873
Change-Id: I7da1883e0970a2f6ddd8385f193b76116d6983e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Currently only available for the OpenSSL backend to use but doesn't
actually rely on anything OpenSSL specific.
Move it so it can be used by the Schannel backend in an upcoming patch
Change-Id: Ia29b153bf3f29cff0d62a41ec5dd7d4671a18095
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
While it's not common it still occurs, perhaps especially with 127.0.0.1
Can be tested by attempting to connect to https://1.1.1.1/ using Qt.
Change-Id: Idad56476597ab570b8347236ff700fa66ab5b1f4
Fixes: QTBUG-71828
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Adds support for Schannel, an SSL backend for Windows, as an
alternative to OpenSSL.
[ChangeLog][QtNetwork][Ssl] Added support for Schannel on Desktop
Windows. To build Qt with Schannel support use '-schannel' during
configure.
Task-number: QTBUG-62637
Change-Id: Ic4fb8ed3657dab994f9f4a4ac5cbddc7001a0a46
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
