This reverts commit 0de6c26ac1.
The patch fixes ambiguity between a getter and a signal by changing the
getter name, but we still have to rename the signal to follow the signals
naming convention.
Revert the commit to keep the getter as is and change the signal name instead.
Change-Id: I67dbb5cada25da473bdd02e71b1e2d9bd03f039e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This way we produce valid xml also for the no-proxy case.
Change-Id: I5a277255d22c3814fe463c0cd013c04ddc6ad919
Reviewed-by: André Hartmann <aha_1980@gmx.de>
In Qt6 QNAM will no longer use bearer in any way so we deprecate it now.
Also mark bearermanagement-conditioned sections for removal in Qt6,
the _q_networksession property is part of how QNAM passes the
QNetworkSession around.
Task-number: QTBUG-81609
Change-Id: I04aad9dd96482c6822dffba1b9af7aa58961149c
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This is part of the migration of qtbase from QRexExp to
QRegularExpression.
If support for regular expression is disabled, fixed string can
still be used.
[ChangeLog][QtCore][QSslCertificate] Add overload of fromPath that does
not make use of QRegExp and deprecate the QRegExp variant.
Task-number: QTBUG-72587
Change-Id: I507d8941cc7d70166da0948375dc421fe5e7d967
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We don't know which versions these blacklistings actually apply on
unless we actually get macOS 10.14 and 10.15 into the CI and running
tests, so let's start with that, and then granularize the blacklists
after that.
Task-number: QTBUG-75786
Change-Id: Id79642afa50cb20efa2cd209286b6933918d3a4a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Same as other versions of MSVC
Fixes: QTBUG-80328
Change-Id: I05c5ffe6d36e0cdfb781080a736c90b6a6d4b2ba
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We were being inconsistent in how we handled this, some tests skipping
while others using QVERIFY. It makes more sense to skip the tests, since
the problem is a missing pre-condition of the test, not the test itself
being bad or exposing real failures in the implementation.
Change-Id: I20eacfe12dbce0b0d926e48cbe2d2772819fa4a5
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
To disambiguate &QSslSocket::sslErrors() expression. Add a new
getter - sslHandshakeErrors().
[ChangeLog][Deprecation Notice] QSslSocket::sslErrors() (the getter) was deprecated and superseded by sslHandshakeErrors()
Task-number: QTBUG-80369
Change-Id: I9dcca3c8499800c122db230753dc19b07654f8a2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QLocalSocket::error is overloaded as a signal and an accessor (for the
error reported by the signal). This means connecting to the signal using
a pointer to member function would require ambiguity resolution. We
deprecate the old accessor (to be removed in Qt 6) and introduce a new one -
'socketError'.
[ChangeLog][Deprecation Notice] QLocalSocket::error() (the getter) is deprecated; superseded by socketError().
Task-number: QTBUG-80369
Change-Id: Iab346f7b4cd1024dee9e5ef71b4b7e09f6d95b12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The one that is a getter for the last error found. This is to disambiguate
the expression '&QAbstractSocket::error'. Introduce a new member-function
socketError as a replacement.
[ChangeLog][Deprecation Notice] QAbstractSocket::error() (the getter) is deprecated; superseded by socketError().
Task-number: QTBUG-80369
Change-Id: Ia2e3d108657aaa7929ab0810babe2ede309740ba
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Windows apparently has special code to deal with those addresses. If all
your network interfaces are up and have acquired addresses, then the
link-local network at 169.254.0.0/16 is unreachable. I had never caught
this because both my Windows VM and my bare metal Windows have inactive
interfaces (like the Bluetooth PAN one) and, when inactive, Windows
assigns a link-local address. But in the CI, the interface(s) were all
up and running, causing this issue.
Unix systems don't treat IPv4 link-local any differently, so they always
worked, so long as any interface was up and there had to be one to reach
the network test server.
This commit reworks the test to add test addresses based on the
addresses found on up & running interfaces (see tst_qudpsocket.cpp). For
IPv4, we flip the bits in the local portion of the address. For IPv6, we
add a node with an address I generated randomly (non-universal), with
the same scope.
Fixes: QTBUG-65667
Change-Id: I568dea4813b448fe9ba6fffd15dd9f482db34991
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This will blacklist this test for ci. Currently blocking enabling tests
for MSVC2019
Task-number: QTBUG-65667
Task-number: QTQAINFRA-2875
Change-Id: I7198490b1529ce2f4409bfa7399031dad7644a06
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Heikki Halmet <heikki.halmet@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Instead of OID as string, OpenSSL returns a human-readable name.
No need to fail then, use such a name in QVERIFY if OID not found.
Fixes: QTBUG-80329
Change-Id: I4392fc9f37367f7c34c05d172db015b44e2a8497
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.
Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
OpenSSL 1.0.2 will stop receiving all support at the end
of 2019. Qt 5.15 is our next LTS thus makes sense remove
OpenSSL 1.0.2 support there. This also allows us quite
a significant cleanup of an old heavily if-defed code
and all 'pre11' suffixed source files.
[ChangeLog][QtNetwork][SSL] Removed OpenSSL 1.0.x support, now 1.1.x is required
Change-Id: I70c70c56cbd8aeff793afe793335696d1b1b7408
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If a transfer timeout is set for QNetworkRequest, downloads
and uploads are aborted if the timeout expires and bytes
haven't been transmitted in either direction.
Task-number: QTBUG-3443
Change-Id: I702d223d673f0c6612343dc9d053815acfcb61b8
Reviewed-by: Mårten Nordheim <marten.nordheim@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>
Following the deprecation of add[Default]CaCertificate[s] let's update
the uses of it. While we're doing this, let's also use QSslConfiguration
more in some places where it makes sense.
Change-Id: I2c9e7c73fee8a405492410378f2babe67d3a3f25
Reviewed-by: Jesus Fernandez <jsfdez@gmail.com>
The requirement to separate debug and release DLLs on Windows stems from
the Visual Studio C run-time library appearing in two different variants
(debug and release) and not mixing well. It's possible to perform builds
without optimzations and with debug symbols while linking against the
release version of the C run-time, but at the same time the debug
version of the run-time brings other developer visible advantages.
MinGW on the other hand does not have this distinction, does not ship
with separate DLLS and does also not require the VS C runtime library.
Therefore we do not need this separation for MinGW, which means that our
packages can be reduced in size and application developers wishing to
debug their applications do not have to use debug builds of the Qt
libraries or run into Qt internal debug code.
Task-number: QTBUG-78445
Change-Id: Idf588606091298dc44262c4c89e689df18d34747
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If the domain passed down is an actual TLD that's the subject of a *
rule, e.g. "ck" subject to *.ck, then we were finding no dot in it and
concluding that it couldn't be the subject of a * rule.
Added a test for the specific .ck case and commented on where we could
get some canonical test data that I tripped over while researching
this. Cross-reference the cookie-jar test from the QUrl test, too.
Fixes: QTBUG-78097
Change-Id: Id858a9dae22e6b306a68df3fc199e0160f537159
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The minimum supported version is Windows 7. Remove
QOperatingSystemVersion::WindowsVista added by
b0cd007335 and replace with "true"
wherever it was used.
Change-Id: I08c0208467b655a921b6773f77d8bc099be69031
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I was observing rare crashes on my mac, where I was using SecureTransport.
This would imply both the client (the test) and the server were working
in h2c mode. But this is against the test's logic - the first request
will be HTTP/1.1 (and upgrading protocol) and I wanted to send 3 HTTP/2
requests instead.
Fixes: QTBUG-77476
Change-Id: I048ca242e2096ca36dd112277807d1fee530150c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
And send it in our 'SETTINGS' frame. Add an auto-test
for this and (as a bonus) - fix a bug accidentally
introduced by the previous change.
Task-number: QTBUG-77412
Change-Id: I4277ff47e8d8d3b6b8666fbcd7dc73c827f349c0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Similar to TLS configuration that we can use on QNetworkRequest,
we can configure different options in our HTTP/2 handling by
providing QNetworkAccessManager with h2 configuration. Previously,
it was only possible internally in our auto-test - a hack with
QObject's properties and a private class. Now it's time to provide
a public API for this.
[ChangeLog][QtNetwork][QNetworkRequest] Add an ability to configure HTTP/2 protocol
Change-Id: I80266a74f6dcdfabb7fc05ed1dce17897bcda886
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This patch was generated with tooling from patchset 31 of
https://codereview.qt-project.org/c/qt/qtqa/+/267034 in interactive
mode. General platform names were chosen if greater than 60% of the
currently active platforms of a given type in COIN recently failed.
Change-Id: Ia4bde7f0ec422bbb727dc9d7151295159094f146
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
some assumptions were incorrect: our test server immediately sends
its SETTINGS frame, as a result we have to reply with client preface +
SETTINGS(ACK). So QVERIFY(!prefaceOK) was wrong from the beginning and
was only passing by pure luck.
Change-Id: Ie43f0d4ac41deb0e5339badaae6149a9b2f9d9b3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
One of the tests above was unsetting a variable that enforces
the use of a temporary keychain. We have to set it back, otherwise
the test is failing. What surprises me though - why I had this
problem only locally and not on CI? Apparently, SecureTransport
is not covered by our configurations ...
Change-Id: I0ff1e3e304632869391ed61213c245b949d8c778
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This change removes the leftovers form other cleanup commits.
Task-number: QTBUG-76491
Change-Id: I61440f87c5a280f9666b78e19aac4d8ac603767e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
