| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Found while cleaning up SPDY remains: I've noticed that for H2 case
I never check if incomingSslConfiguration is nullptr or not, but
the code several lines below - does it, which looks kind of moronic.
This configuration is initialized when the delegate is created, so
no need to have this if-statement. Instead, assert, making this
behavior a requirement.
Change-Id: I90fb84337be925a3288252aa2491b4c23d6c6cbb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
| |
Found while preparing SPDY retirement.
Change-Id: I30f923fdeb0f6f0b5e808a3e7b7d81ddb9c4ef12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\
| |
| |
| | |
Change-Id: I371c5ae1af6f58e32e579671f485b92b586e0b76
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While working with HTTP/2, we are not re-sending failed requests.
In case we receive a GOAWAY frame, we properly handle it by
processing some active streams if possible, and aborting streams
that will not proceed further with ContentResendError. But it's
possible that some server failed to send us GOAWAY (for example,
it died) or closed the connection not finishing the streams that
were still active and valid (ID <= value from GOAWAY frame).
Now that we will not re-connect, there is no reason to be quiet
about us not progressing - emit RemoteHostClosedError on any
remaining active stream/request we cannot process further.
Fixes: QTBUG-77852
Change-Id: I4cd68a1c8c103b1fbe36c20a1cc406ab2e20dd12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 543769666f18f79bd6ebd6119a39834aafc2b0df)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The _q_error slot has a special case for RemoteHostClosedError,
where the current channel's state is 'idle' and no request/reply
is in progress. The comment states that:
"Not actually an error, it is normal for Keep-Alive connections
to close after some time if no request is sent on them. No need
to error the other replies below. Just bail out here. The _q_disconnected
will handle the possibly pipelined replies."
_q_disconnected, indeed, takes care about pipelined replies ... calling
'ensureConnected' even if we have 0 replies in pipeline, which makes
zero sense to me and results in QNAM endlessly trying to re-connect
to the server.
Fixes: QTBUG-77852
Change-Id: I6dcb43b36a6d432bc940246a08f65e1ee903fd24
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I9823da32168e99bbece2f8337d0bd4d33e6d634c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the end range of a byte range in a HTTP request is skipped the download
manager adds 0 it its place when resuming that download.
When there is no end range given the value is skipped.
Task-number: QTBUG-77867
Change-Id: I52358c94cf56c88217fcc91abb102ed393ac7242
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This should help when things are moving fast, and downloads and
network object are destroyed before the callbacks finishes.
Change-Id: I1f65965bd61efc2e641d03eb071f23e684dd5c44
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\|
| |
| |
| | |
Change-Id: Id7954ada1f8658d3b1da5e8241a09f2d201a7c56
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some servers seem to be unable to properly calculate our window size
from a delta we send via WINDOW_UPDATE frame immediately after our
client preface and the SETTINGS frame. The remote replies with a
GOAWAY frame blaming flow control error. Guessing what's this
magic number they use seems to be not feasible, we now use a
half of what we had before.
Fixes: QTBUG-77308
Change-Id: I41dacfd25a395a27003f330d01b6d8d60b8f407c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Need to pass correct buffer size
Change-Id: I19cb65114f49decc225cd807d59f1f08ad6b70c9
Fixes: QTBUG-76212
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/access/qhttpthreaddelegate.cpp
Change-Id: Id47b977587e2d713c16ac17e63c5ec80c2f05ee9
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QNetworkAccessManager::connectToHostEncrypted()/connectToHost()
creates 'fake' requests with pseudo-schemes 'preconnect-https'/
'preconnect-http'. QHttp2ProtocolHandler should handle this
requests in a special way - reporting them immediately as
finished (so that QNAM emits finished as it does in case of
HTTP/1.1) and not trying to send anything.
We also have to properly cache the connection - 'https' or
'http' scheme is too generic - it allows (unfortunately)
mixing H2/HTTP/1.1 in a single connection in case an attribute
was missing on a request, which is wrong.
h2c is more complicated, since it needs a real request
to negotiate the protocol switch to H2, with the current
QNetworkHttpConnection(Channel)'s design it's not possible
without large changes (aka regressions and new bugs introduced).
Auto-test extended.
Fixes: QTBUG-77082
Change-Id: I03467673a620c89784c2d36521020dc9d08aced7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The QNetworkReply implementation for Qt for WebAssembly now supports
usage of the QNetworkAccessManager::sendCustomRequest, making it
possible to send requests with custom verbs.
[ChangeLog][QtNetwork][QNetworkAccessManager] Fixed
QNetworkAccessManager::sendCustomRequest for Qt For WebAssembly.
Fixes: QTBUG-76775
Change-Id: I9394ffef110fce4ed2c877893631bedc7631f71e
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
|
|\|
| |
| |
| | |
Change-Id: I912bd8851c390302414d3dfb3c8220df5a0d5630
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When using a http proxy (and presumably other proxies) we might have
failed/aborted (aka "finished") the request and _then_ receive a
"proxy authentication required" message from the proxy. In this case
there is no spdy/http2 reply in the queue, so asserting is wrong.
Change-Id: Id9b76b580299f6a6cd6efad62d6aaf63183816fb
Fixes: QTBUG-76426
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In some scenarios with QNAM we call socket->close, leading to a flush,
leading to an error, leading to another error emission... To work
around this scenario we stop trying to close the socket if the network
channel is already closing.
Change-Id: Id15504f476484ce61f11ba83a5755ceb5f581f9b
Fixes: QTBUG-76567
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
also fix data progress
Task-number: QTBUG-75489
Change-Id: I5222fda64d258a6ae78ba0ca20194b81c289c27e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
this also optimizes network post method handling
Task-number: QTBUG-75660
Change-Id: Ibb0d01f2cc2b2bc7802598c4f6f04b04882c12ca
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/pcre2/qt_attribution.json
Change-Id: Ibae941cb12662f27bd6962ee02bc235971c59a15
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously there were two issues:
- A QNetworkReply could be aborted but be in NoError state.
(GOAWAY frame with 0 as error)
- Streams in a connection would be aborted prematurely when a GOAWAY
frame with a lastStreamId of 2^31-1 was received.
Fixes: QTBUG-73947
Change-Id: Iddee9385c1db3cc4bb80e07efac7220fff787bf3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| | |
Change-Id: I9935bacae0d6ba532418fc3d28adbc7ca1463604
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After 'h2c' mode was implemented with the proper protocol
upgrade, the previously working 'direct connection' mode
was lost for clear text connections due to the erroneous
logic in the constructor: having !channel->ssl does not
necessary mean we started with HTTP/1.1 request, including
protocol upgrade header; it can also mean we connected a
plain socket and immediately sending h2 frames, without
any H2 negotiation at all.
Fixes: QTBUG-74765
Change-Id: Ice466d6bffb40048b7ab46fb064f2d3d795a12aa
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Prevent namespace collisions and make sure Qt functions
are grouped together.
Change-Id: I217188ee93e4300e273d10a79d6014179fc5a1ef
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
|
|\|
| |
| |
| | |
Change-Id: I71cc71881fb638e207d83a8733bad8f267701c0f
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We can pass these through to to the browser, which
will resolve them relative to the current html file.
Task-number: QTBUG-74289
Change-Id: I595f30456de55da4f1432fb997d381940f51c5f9
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
|
| |
| |
| |
| |
| |
| | |
Fixes: QTBUG-73346
Change-Id: I8aaf8fe45f3014e2c9187c554ed86a4d29c03c0b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
|\|
| |
| |
| | |
Change-Id: Ica3f89ace33585ad7854417a328156f5a68e2a00
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As explained in the inline comment we don't actually have a
protocol handler until we're done encrypting when we use SSL, but we
would still retry the connection if an error occurred between
"connected" and "encrypted". This would then lead us to fail an assert
that checked if a protocol handler had been set
Fixes: QTBUG-47822
Change-Id: If7f4ef4f70e72b764f492e7ced5a9349b3a421d2
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
src/network/access/http2/hpacktable_p.h
Change-Id: Ie0c296667dfdebba84f4858056a1ac80c24ee7df
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This would only ever put the first 16k into the buffer that gets read,
so this 16k would get repeated until the size of the download.
Task-number: QTBUG-74123
Change-Id: Ia53bedf6a8754d9fd83fd0ab62866cfa5af5cc1a
Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
|
| |
| |
| |
| |
| | |
Change-Id: Ie9992f67ca59aff662a4be046ace08640e7c2714
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
Replace null and '\c nullptr' with \nullptr in the documentation.
Change-Id: I58934eea06943309ba895833f1991629870ab45b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
[-Wclazy-incorrect-emit]
Change-Id: I32cf5db522dcb14bbe5151914624979929eeb52e
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
[-Wclazy-incorrect-emit]
Change-Id: I21f69d7f6b161d70a687ab17b2821a595c113ec7
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/android/templates/AndroidManifest.xml
src/network/ssl/qsslsocket_mac.cpp
src/widgets/styles/qstylesheetstyle.cpp
tests/auto/corelib/kernel/qtimer/BLACKLIST
tests/auto/testlib/selftests/blacklisted/tst_blacklisted.cpp
tests/auto/testlib/selftests/expected_blacklisted.lightxml
tests/auto/testlib/selftests/expected_blacklisted.tap
tests/auto/testlib/selftests/expected_blacklisted.teamcity
tests/auto/testlib/selftests/expected_blacklisted.txt
tests/auto/testlib/selftests/expected_blacklisted.xml
tests/auto/testlib/selftests/expected_blacklisted.xunitxml
tests/auto/testlib/selftests/expected_float.tap
tests/auto/testlib/selftests/expected_float.teamcity
tests/auto/testlib/selftests/expected_float.txt
tests/auto/testlib/selftests/expected_float.xunitxml
Done-With: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Done-With: Timur Pocheptsov <timur.pocheptsov@qt.io>
Change-Id: If93cc432a56ae3ac1b6533d0028e4dc497415a52
|
| |
| |
| |
| |
| |
| |
| | |
...for a minor performance gain.
Change-Id: I4bef867055e069926fdc24fa98a6f94b6a0630e2
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The protocol handler now matches HTTP/1.1's protocol handler.
Change-Id: Id55c10900e2bcd46e5dc65c63db77097eb4818b6
Fixes: QTBUG-73364
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds functions to QNetworkRequest to be able to set the
peerVerifyName. An overload of connectToHostEncrypted is also added to
have an extra argument to allow setting it directly in this manner too.
Fixes: QTBUG-73125
Change-Id: I371e90035b53a74c9eb3cef64f367e307dce073e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Replace 0 with \nullptr in the documentation.
As a drive-by also replace some 0 with nullptr in the corresponding
code.
Change-Id: I914b6b2151554c06acc2d244eff004524cbb9a82
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
Change-Id: Ibfcb30053f3aacb8ec2ec480e146538c9bf440ea
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Q_DECLARE_PRIVATE gets used in the declaration of the public class,
where the private class is typically visible only as a forward-decl,
with no knowledge of what it's based on; consequently, the macro is
obliged to use reinterpret_cast<>, which is subject to warnings when
the compiler *can* see both types and their alignments differ. The
same applies to Q_DECLARE_PRIVATE_D.
So suppress gcc's -Wcast-align around the d_func() return statements.
(If we get similar problems with other compilers we can add their
suppressions likewise; but, for now, we've only seen this on MIPS64,
where we use gcc.) This tripped over one use of Q_DECLARE_PRIVATE in
a private Q_SLOTS: section; for some reason, gcc didn't like the
semicolon on the friend declaration. Changing the context to plain
private fixed that.
Fixes: QTBUG-72885
Change-Id: I5edc11d46bd4eb820713adede79d53191a7e2736
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Boxiang Sun <daetalusun@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Qt for Python users reading the documentation assume that int(0) can
be passed for pointer parameters. Use the newly introduced \nullptr to
disambiguate this.
In a follow-up step, the \nullptr macro can be defined as None
when generating the Qt for Python documentation.
Task-number: PYSIDE-903
Change-Id: I3a45f87175a0668ab5f3f95f0aff409f7e3ef027
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Christian Tismer <tismer@stackless.com>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
|
| |
| |
| |
| |
| |
| | |
Change-Id: I34a8ec05c18b15ed71787986b5b0316693235b4d
Fixes: QTBUG-72105
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since it explains nothing and now, after some other bug was fixed
(see, for example, c89d0f9d532), we trigger this message on the
first request, which happens because:
- 'createSession()' indeed, creates a session, compares a previous
kwnon state (which happens to be 'Invalid') with a current state,
which is 'Connected' and then invokes '_q_networkSessionStateChanged'.
- '_q_networkSessionStateChanged()' on 'Connected' emits
'networkSessionConnected()' to which a newly-created QNetworkReplyHttpImpl
will respond with it's _q_startOperation().
- QHttpNetworkReplyImpl will also try to 'open' a session, its 'opened()'
signal will trigger, again, 'networkSessionConnected()' and ... the
next _q_startOperation().
Now, not to add even more twisted spaghetti if/conditions with some
unpredictable regressions, let's suppress a useless warning and
silently return. We, indeed, in 'Working' state, let's keep working.
Task-number: QTBUG-72463
Change-Id: I5282979920915ffded889c20b8ae740a46efef04
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also blacklist tst_QRawFont::unsupportedWritingSystem() and
tst_QGlyphRun::mixedScripts() on windows for now.
Conflicts:
qmake/generators/makefile.cpp
src/corelib/itemmodels/qstringlistmodel.cpp
src/platformsupport/fontdatabases/windows/qwindowsfontengine_p.h
tests/auto/corelib/itemmodels/qstringlistmodel/tst_qstringlistmodel.cpp
tests/auto/gui/text/qglyphrun/BLACKLIST
tests/auto/gui/text/qrawfont/BLACKLIST
Task-number: QTBUG-72836
Change-Id: I10fea1493f0ae1a5708e1e48d0a4d7d6b76258b9
|
| |
| |
| |
| |
| |
| | |
Change-Id: I23445f5e0c936b82aa5d65b261d456a563deab9a
Fixes: QTBUG-72516
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I think this may have been for some POST method form queries, but
obviously was missing something.
Task-number: QTBUG-72382
Change-Id: I59016776aeedf4b5599b3b44af70610babb0a61e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Ryan Chu <ryan.chu@qt.io>
|