When the connection has been encrypted we will,
in QHttpNetworkConnectionChannel::_q_encrypted, emit 'reply->encrypted'
in which user slots can be called.
In the event that the user calls abort it will, however, not abort until
the next time it goes back to the event loop (which might not happen
until after the request has already been sent).
Task-number: QTBUG-65960
Change-Id: I96865f83c47f89deb9f644c86a71948dbb0ec0d0
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This change frees the tests of their dependence on the Qt internal test
server (qt-test-server.qt-test-net). It makes the developers run the
tests out of Qt testing infrastructure.
If the user has installed Docker engine on their host, the test servers
will be built up inside separate Docker containers, and then, the test
case goes with the Docker-based test servers. Otherwise, the test case
will keep using the Qt internal test server.
Task-number: QTQAINFRA-1686
Change-Id: I518bc3675bfd658938509744b0e7e0610bc8bf66
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@qt.io>
This only enables compilation, it doesn't fix any test.
Qt on Android supports process, but not TEST_HELPER_INSTALLS. See also
acdd57cb for winrt.
android-ndk-r10e is used to compile, see
http://doc-snapshots.qt.io/qt5-5.11/androidgs.html .
corelib/io/{qdir,qresourceengine} need to be fixed later.
Done-with: Frederik Gladhorn <frederik.gladhorn@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I34b924c8ae5d46d6835b8f0a6606450920f4423b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
It was the same in all test rows, so move it from the _data() to a
fixed value in the test. Also, don't implicitly coerce C-string
literals to QString.
Change-Id: Ieee4c7ffbf251c4b69b5acd79125dfa93eb51d6e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Unlike QNAM, our toy http2 server sends payload as one big chunk as soon as
it fits in the receive window's size. Internally, 'frame writer' splits this
payload into many DATA frames of the appropriate size (imposed either by the
default value or the one from the client's SETTINGS frame). If some test fails,
we can end up with a server waiting for the writer to send all the DATA frames
though it is not needed anymore - there is nobody to receive them after a failure.
This patch moves such a loop into the test server instead and stops the loop early
if needed.
Change-Id: Iea2dcd718d8f83386fd16004807f6447bf999435
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Replace with QSignalSpy or QTRY_COMPARE when possible.
Task-number: QTBUG-63992
Change-Id: I18dc8837301424855487a12ee62451a5aeb21bf0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
... but only if the host it came from is an EXACT match. Also only apply
the cookie if the url is an EXACT match.
[ChangeLog][QtNetwork][QNetworkCookieJar] Cookies will no longer be
rejected when the domain matches a TLD. However (to avoid problems
with TLDs), such cookies are only accepted, or sent, when the host name
matches exactly.
Task-number: QTBUG-52040
Change-Id: Ic2ebd9211c48891beb669032591234b57713c31d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QNetworkRequest is already aware of the Last-Modified header but
has been lacking support for the If-Modified-Since, ETag, If-Match
and If-None-Match headers. These headers are used with HTTP to
signal conditional download requests.
See RFC 7232 for more information.
Change-Id: I248577b28e875fafd3e4c44fb31e8d712b6c14f1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTestEventLoop (conveniently so) takes care of timeouts thus no
external QTimer/handling logic needed at all.
Change-Id: Id65ea928daec1e7d9380107e63916896f19d3d14
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
1. If a request was redirected or some error was encountered, we
try to reset the uploading byte-device.
2. Disconnecting from the byte-device is not enough, since we have a
queued connection, _q_uploadDataReadyRead() gets called even if
byte-device was deleted and thus sender() can return null -
we have to check this condition.
3. Update auto-test with a case where our server immediately
replies with a redirect status code.
Task-number: QTBUG-67469
Task-number: QTBUG-66913
Change-Id: I9b364cf3dee1717940ddbe50cba37c3398cc9c95
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When network access is disabled, every QNAM request returns a
QDisabledNetworkReply instance, which emits error and finished
immediately. However isFinished() was still false, which could confuse
application code.
Change-Id: Ifd43c86364b11a9583a38fde536e6c09c109b55f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Has been failing a lot lately
Task-number: QTBUG-66247
Change-Id: Id940a573eb299379cacceb836890cbe0b3c896b7
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Without this fix, a fresh clean build of 5.9 will fail.
Change-Id: I69e4da382b07cc6e5e280e99478cbc3d44aa3f27
Reviewed-by: Jesus Fernandez <Jesus.Fernandez@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The code used to fall back to anonymous login independently for username
and password; however, it should only use a fall-back password if the
username is missing or (case-insensitive) "anonymous". When a
non-anonymous username is given without password, we should simply skip
he PASS message to FTP.
If the FTP server requests a password, in the latter case, QFtp will
signal authenticationRequired; in all cases, if the server rejects the
given credentials, QFtp signals authenticationFailed. Either way, the
client code can then query the user for credentials as usual.
Task-number: QTBUG-25033
Change-Id: I2a4a3b2725819ab19c8a7e4baa431af539edcd8d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
setSession is only used if we have bearer management.
Change-Id: I64b9d29c01566e79bbca5d0dc11d6aee6d9b0bf0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This test became a real pain recently. A close look at the test shows
several problems (strangely enough, the failure can never be
reproduced on real machines, only on VM - Ubuntu and RHEL 6.6).
There are several asserts that are firing from time to time here and
there. They show that the logic in test is broken/incorrect. QNAM can
open several connections to a host, our test then incorrectly resets
its 'client' data-member and bad things can later happen after
'bytesWrittenSlot' executed (and deleted a socket). For example,
I can reproduce this scenario in every second run:
1. incoming connection -> client = socket(descriptor), connect to
client's readyRead (s1)
2. incoming connection -> client = socket(descriptor), connect to
client's readyRead (s2)
QNAM sends a request on s1. We reply on s2 (which is already wrong)
and call client->deleteLater(), which resets client to nullptr.
If QNAM sends something else on s1, we hit assert(!client.isNull()).
To avoid this, whenever 'sender' in any slot is different from the
'client', we use the actual 'sender' to reply. Another problem is this
weird and rather cryptic waitForFinish which is not needed in this
particular test since we wait for reply error, not 'finished'.
As it happened before - it's not clear if these two problems
were the cause of guaranteed fails on CI - an integration failed
~10 times in a row in the same test (not happening anymore though).
Task-number: QTBUG-64569
Change-Id: Id9aa091290350c61fadf1c3c001e7c2e1b5ac8f4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also blacklist tst_QNetworkReply::ioHttpRedirectErrors(too-many-redirects)
on RHEL 6.6 in CI.
Conflicts:
tests/auto/network/access/qnetworkreply/BLACKLIST
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Task-number: QTBUG-64569
Change-Id: I7514fc0660c18fd3a3e1d0d0af3f15d879e3c6f4
Looking at the failures in grafana it appears this test is also failing
on Windows 64. The same fix applies then, and we use Q_OS_WIN now.
Change-Id: Iafcfd6d1e747f3c816878cad072fbfae3aee19ca
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch works around Windows X86 on QEMU antics.
It appears on this platform the test behaves in some unpredictable manner:
- WSAConnect with 255.255.255.255 does not always immediately fail with
some error, so socket engine waits for a connection timeout (30 s.),
but the test itself
- only waits for 5 seconds and then tests that a request has finished with
error, which is not true (we are still connecting).
To make it work - whenever we have bearermanager feature enabled, set
a connection timeout to something reasonable, not 30 s.
Since we try to connect to each address twice, make timeout 1.5 s
(so it's 3 s. in total and still is < 5 s.).
Task-number: QTBUG-64264
Change-Id: I1d40c140667fca8402ec9344e66d313b6df54256
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The vast majority is actually switched to QRandomGenerator::bounded(),
which gives a mostly uniform distribution over the [0, bound)
range. There are very few floating point cases left, as many of those
that did use floating point did not need to, after all. (I did leave
some that were too ugly for me to understand)
This commit also found a couple of calls to rand() instead of qrand().
This commit does not include changes to SSL code that continues to use
qrand() (job for someone else):
src/network/ssl/qsslkey_qt.cpp
src/network/ssl/qsslsocket_mac.cpp
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- Blacklist ioHttpRedirectPostPut for Windows
- Amend 84396a3f93:
Keys need to be on subsequent lines
Task-number: QTBUG-62583
Change-Id: I6360ec7bd87de65a3294a0d22148f13579fcd292
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
While removing insignificant flag in commit
38a0909d4e and blacklisting
autotests that still failed, qtbase builds didn't
verify VS2017. That broke qt5 builds which do build VS2017.
Task-number: QTBUG-64264
Change-Id: I5fdfa5dac6192f449a05146a9a422e428a710c84
Reviewed-by: Liang Qi <liang.qi@qt.io>
This test fails often and seems to be flaky.
Task-number: QTBUG-62583
Change-Id: Id3af283c89e392634a7af6e11bd05775a4295798
Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
Neither the exit crash of QTBUG-21102 nor the Windows failure of
QTBUG-24226 appear to be reproduceable.
Add verbose error reporting to getErrors() and blacklist
getErrors:ftp-host which has been found to fail with timeouts
on Linux and ioHttpRedirectMultipartPost.
Task-number: QTBUG-21102
Task-number: QTBUG-24226
Task-number: QTBUG-62860
Change-Id: I6b29f6184e83de8ffebf6ff0d80606512dca6419
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
