| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have a proper ALPN/NPN + Protocol Upgrade, we can also
add H2Direct - this can be useful for our users that have to work
with either Secure Transport or a TLS implementation not supporting
ALPN/NPN and with 'h2direct' servers in case they have prior knowledge
of HTTP/2 support. The difference with RFC 7540 is the fact we also
allow this 'direct' in case of 'https' scheme (it appears existing
HTTP/2 server implementations support such mode too).
[ChangeLog][QtNetwork] Add Http2DirectAttribute to enable 'direct' HTTP/2
protocol without ALPN/NPN and without protocol upgrade negotiations.
Task-number: QTBUG-61397
Change-Id: I0499d33ec45dede765890059fd9542dab236bd5d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without TLS (and thus ALPN/NPN negotiation) HTTP/2 requires
a protocol upgrade procedure, as described in RFC 7540, 3.2.
We start as HTTP/1.1 (and thus we create QHttpProtocolHandler first),
augmenting the headers we send with 'Upgrade: h2c'. In case
we receive HTTP/1.1 response with status code 101 ('Switching
Protocols'), we continue as HTTP/2 session, creating QHttp2ProtocolHandler
and pretending the first request we sent was HTTP/2 request
on a real HTTP/2 stream. If the first response is something different
from 101, we continue as HTTP/1.1. This change also required
auto-test update: our toy-server now has to respond to
the initial HTTP/1.1 request on a platform without ALPN/NPN.
As a bonus a subtle flakyness in 'goaway' auto-test went
away (well, it was fixed).
[ChangeLog][QtNetwork][HTTP/2] In case of clear text HTTP/2 we
now initiate a required protocol upgrade procedure instead of
'H2Direct' connection.
Task-number: QTBUG-61397
Change-Id: I573fa304fdaf661490159037dc47775d97c8ea5b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/plugins/platforms/cocoa/qcocoamenu.h
src/plugins/platforms/cocoa/qcocoamenu.mm
src/plugins/platforms/cocoa/qcocoawindow.mm
src/widgets/styles/qstylehelper_p.h
Change-Id: I54247c98dd79d2b3826fc062b8b11048c9c7d9bb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we reach the maximum reconnect attempts for an HTTP request with
pipelining enabled, those also need to be requeued during cleanup for
the connection channel. Otherwise future successful requests on that
same channel will incorrectly assign the data to replies from the old
pipelined requests, resulting in swapped data in the replies.
Task-number: QTBUG-62286
Change-Id: I804b8ac280957b518d63b2341e469a13315a8c27
Reviewed-by: Markus Goetz (Woboq GmbH) <markus@woboq.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's really unfortunate that even a plain 'http' request results in
(Open)SSL initialization; this is apparently done by QSslConfiguration's
default constructor and we have several classes including QSslConfiguration
as a data-member.
There are different problems reported because of this, from crashes
(a broken OpenSSL on Windows) to long initialization times, which is
not acceptable if no 'https' request was actually executed.
This patch-set is replacing data-members of type QSslConfiguration
with smart-pointers and delays (Open)SSL initialization.
Task-number: QTBUG-59750
Change-Id: Id1d375e689dbd2d134abbb0572a9e804d595110e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/plugins/platforms/eglfs/eglfs-plugin.pro
Change-Id: Id76cdbb41b7758572a3b8ea4dcb40d49bac968db
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Both SPDY and HTTP/2 work with a single qhttpnetworkchannel (and this means one
socket per qhttpnetworkconnection). Normally, HTTP/1.1 connection is using up to 6
channels/sockets though. At the moment a failure to negotiate SPDY/HTTP/2 leaves us
with a downgraded HTTP/1.1 connection (with only one channel vs. default 6).
Since we initialize channels (and establish connections) in a 'lazy' manner
it's ok to pre-allocate all 6 channels and then either use 1 (if SPDY/HTTP/2
indeed was negotiated) or switch back to 6 in case of failure.
Change-Id: Ia6c3061463c4d634aaed05ce0dde47bfb5e24dd8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 556b2ee7737b1dfdbc5223e9a1230b5df6843a01.
The reason for this is that this change appears to stop
QtLocation from fetching tiles.
Task-number: QTBUG-58303
Change-Id: I64cd3a17d24f10652bb68cee0267cc7ff1f9d479
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
mkspecs/common/msvc-desktop.conf
mkspecs/common/msvc-version.conf
mkspecs/common/winrt_winphone/qmake.conf
mkspecs/features/mac/default_post.prf
mkspecs/features/mac/sdk.prf
mkspecs/features/qt.prf
mkspecs/features/uikit/default_post.prf
mkspecs/features/winrt/default_pre.prf
mkspecs/winphone-arm-msvc2013/qmake.conf
mkspecs/winphone-x86-msvc2013/qmake.conf
mkspecs/winrt-arm-msvc2013/qmake.conf
mkspecs/winrt-x64-msvc2013/qmake.conf
mkspecs/winrt-x86-msvc2013/qmake.conf
qmake/generators/win32/msvc_vcproj.cpp
src/gui/kernel/qwindowsysteminterface.cpp
src/network/kernel/qhostaddress.cpp
src/plugins/platforms/mirclient/qmirclientplugin.cpp
src/plugins/platforms/mirclient/qmirclientplugin.h
src/widgets/util/qsystemtrayicon.cpp
tests/auto/widgets/itemviews/qlistview/tst_qlistview.cpp
tools/configure/Makefile.mingw
tools/configure/Makefile.win32
Done-with: Jake Petroules <jake.petroules@qt.io>
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: I4be3262d3994e11929d3b1ded2c3379783797dbe
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GCC 7 warns about implicit fall-throughs now.
Fix by adding the missing Q_FALLTHROUGH(), and, in one case, by
moving the existing suppressant into the correct position.
Change-Id: I7383f47e690b6334ef69c9df745c2205247ca7d0
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We observed a stack-trace in which, while handling an error,
QHttpNetworkConnectionChannel::close()'s call to its socket->close()
triggered (when the socket was a QSslSocket) a flush() which asked its
backend to transmit() which tripped over the original error, which
duly triggered endless recursion. Transiently clear the socket
member, during its ->close(), to prevent this; do the same in abort(),
to preserve its structural correspondence to close(). Restructure
both so that any recursive call's setting of state is overwritten by
the top-level call's, while this still uses the prior socket state
(not the state after close() or abort() and any recursion) to
determine final state.
Task-number: QTBUG-56476
Change-Id: If69e97f7a77a729bf2338ed14214c65aa95f8b05
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix the case when we erroneously handled stream ID == 0 in a GOAWAY frame as
an invalid stream ID.
- _q_receivedReply: convert do{}while() loop into to while(){} to prevent
it from handling any frames after GOAWAY frame received and all active frame
finished.
- sendRequest - if we received GOAWAY, also clear spdyRequests in the connection
channel, otherwise it keeps re-trying to send requests!
- Http network connection channel never resets a protocolHandler in _q_encrypted/
_q_connected, which is BAD for HTTP/2, since HTTP/2 has unique per-connection
compression context and must be reset - now we recreate the protocol handler in
_q_encrypted or _q_connected (https/http).
- Update autotest.
Task-number: QTBUG-57600
Change-Id: Ib864ce52287bab23334ff43a83ba4b0b7cb52c60
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/gui/image/qpixmap.cpp
src/widgets/kernel/qformlayout.cpp
Change-Id: I8a8391a202adf7f18464a22ddf0a6c4974eab692
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/network/access/qhttpnetworkconnection.cpp
src/network/access/qhttpnetworkconnection_p.h
Change-Id: I11f8641ef482efa8cee1b79977d19cc3182814b4
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In some cases, when QNetworkReply::encrypted is emitted,
QNetworkReply::sslConfiguration is not yet initialized, in particular
certificate chain is empty, which breaks the documented usage of
'encrypted' to perform additional checks on certificate chain.
It looks to be caused by the fact that QHttpNetworkReply is originally
associated with 0th QHttpNetworkConnectionChannel, and this association
is not updated if HTTP pipelining is not used. Therefore, a reply on
channel >0 might arrive before reply on channel 0, and then using ssl
configuration from channel 0, which not made it through handshake, is
not usable.
Task-number: QTBUG-49554
Change-Id: Ie5d4b5a0c503d5bdc44761ce8581f6ffe4e3bac2
Reviewed-by: Markus Goetz (Woboq GmbH) <markus@woboq.com>
|
|\ \ \
| | | |
| | | |
| | | | |
Change-Id: I41ee7b50534b01cf042bed8bb8824ba2e5026a29
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Recently enabled cleartext fails to build with QT_NO_SSL - fix
test and QNAM.
Change-Id: I467edab8e4eb5113715ad2d3b3022e0d8c027de8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
HTTP/2 does not require TLS connection, it can work in a cleartext mode.
Plus at the moment only OpenSSL backend allows HTTP/2 negotiation
via ALPN/NPN (and none of our CI configurations with OpenSSL supports
these extensions, rendering HTTP/2 auto-test useless). This patch
implements cleartext HTTP/2 ('h2c') in 'direct' mode - this is
allowed if a client has a prior knowledge that HTTP/2 is supported by
a server.
Change-Id: I4978775e9732c40bc77f549b83bb4a5d1761887e
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Replaces our mix of comments for annotating intended absence of break
in switches with the C++17 attribute [[fallthrough]], or its earlier
a clang extension counterpart.
Change-Id: I4b2d0b9b5e4425819c7f1bf01608093c536b6d14
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 12d71f4ea20415ff2274e1e90f9e4d5a8b935d7f.
This change is breaking a build + incomplete as my test revealed.
Will have to re-try later.
Change-Id: I7ea089093a832aa5822caaaac56e62f5fda4df17
Reviewed-by: Liang Qi <liang.qi@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without ALPN/NPN (== without OpenSSL) we can negotiate HTTP/2
using the protocol upgrade procedure as described by RFC7540.
Since there is no TLS handshake, after our http channel was connected
we first send an 'augmented' HTTP/1.1 request - its header
contains additional 'HTTP2-Settings' and 'Upgrade' (to 'h2c') fields.
If we receive reponse 101 (switch protocol) we re-create a protocol
handler and switch to HTTP/2.
Task-number: QTBUG-50955
Change-Id: I36e9985e06ba76edaf7fdb22bb43770f8d593c61
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
On Windows, qsslcontext_openssl_p.h pulls in an unsanitized
windows.h, causing the infamous min/max macros to be defined,
requiring a #define NOMINMAX in qhttp2protocolhandler.cpp.
This in turn breaks the MinGW developer build since that has
NOMINMAX globally defined:
access\qhttp2protocolhandler.cpp:40:0: error: "NOMINMAX" redefined [-Werror]
Remove the include, adding missing forward declarations and include
directives to the source files.
Change-Id: Ic1c2c711d87599b15ad6e2d87eae7153a44ace47
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add HTTP2 support in QNAM - QHttp2ProtocolHandler + aux. classes.
[ChangeLog][QtNetwork] Added support for HTTP/2 protocol
Task-number: QTBUG-50956
Change-Id: I3a119cfbb1fb3118d9003225f5e54b46ae2829b6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
config.tests/unix/nis/nis.cpp
mkspecs/unsupported/freebsd-g++/qplatformdefs.h
src/corelib/tools/qdatetime.cpp
src/corelib/tools/qsimd.cpp
src/corelib/tools/qsimd_p.h
src/network/access/access.pri
src/network/access/qnetworkreplynsurlconnectionimpl.mm
src/network/access/qnetworkreplynsurlconnectionimpl_p.h
src/plugins/platforms/cocoa/qnsview.mm
src/plugins/printsupport/windows/qwindowsprintdevice.cpp
tests/auto/corelib/kernel/qobject/tst_qobject.cpp
tests/auto/network/access/qnetworkreply/BLACKLIST
tests/auto/widgets/widgets/qopenglwidget/BLACKLIST
Change-Id: I4b32055bbf922392ef0264fd403405416fffee57
|
| |
| |
| |
| |
| |
| |
| |
| | |
A port was being assigned to qint16 instead of quint16.
Change-Id: I9414e2dcca52beab1bc17ef61cfff56db8ab83a0
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The printf-style version of QDebug expands to a lot less code than the
std::ostream-style version. Of course, you pay in type safety (but
compilers warn about it these days), you cannot stream complex Qt
types and streaming QStrings is awkward, but in many cases you
actually improve on readability.
But the main reason is that something that's not supposed to be
executed under normal operation has no business bloating executable
code size.
This is not an attempt at converting all qWarnings() to printf-style,
only the low-hanging fruit.
In this first part, replace
qWarning() << ""
with
qWarning("...").
Saves ~850b in text size on optimized GCC 5.3 AMD64 builds.
Change-Id: Ib1a087795a03b2a6b432e2c499968df779aaea37
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Otherwise, we have unexpected channel close initiated by reply
destructor.
Change-Id: I15ad076ff20546e78787e19155544a2e5f8047a1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Markus Goetz (Woboq GmbH) <markus@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A QAbstractSocket can be close()'d at any time, independently of its
current connection state. being closed means that we cannot use it to
read or write data, but internally it might still have some data to
send or receive, for example to an http server. We can even get a
connected() signal after close()'ing the socket.
We need to catch this condition and mark any pending data not yet
written to the socket for resending.
Task-number: QTBUG-48326
Change-Id: I6f61c35f2c567f2a138f8cfe9ade7fd1ec039be6
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
qmake/doc/src/qmake-manual.qdoc
src/corelib/tools/qstring.h
src/gui/image/qimagereader.cpp
src/network/access/qnetworkaccessmanager.cpp
src/tools/qdoc/doc/examples/examples.qdoc
src/widgets/accessible/qaccessiblewidgetfactory_p.h
src/widgets/doc/qtwidgets.qdocconf
Change-Id: I8fae62283aebefe24e5ca4b4abd97386560c0fcb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we abort a connection in QNetworkReply::encrypted the underlying
socket gets flushed. This patch fixes that no data will be transmitted
after someone called abort().
Change-Id: I59306e69cb9f2e1421b324e11947375130e52135
Task-number: QTBUG-47471
Reviewed-by: Markus Goetz (Woboq GmbH) <markus@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There can be a race condition where another channel connects
and gets the sslErrors() from the socket first. Then the
QSslConfiguration from the wrong socket (the default
channel 0's socket) was used.
Task-number: QTBUG-18722
Change-Id: Ibbfa48c27f181563745daf540fa792a57cc09682
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
qmake/doc/snippets/code/doc_src_qmake-manual.pro
qmake/doc/src/qmake-manual.qdoc
src/corelib/io/qstorageinfo_unix.cpp
src/corelib/tools/qbytearray.cpp
src/widgets/kernel/qwidgetwindow.cpp
tests/auto/corelib/io/qprocess/tst_qprocess.cpp
tests/auto/corelib/mimetypes/qmimedatabase/tst_qmimedatabase.cpp
tests/auto/network/access/qnetworkreply/BLACKLIST
Change-Id: I9efcd7e1cce1c394eed425c43aa6fce7d2edf31c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The _q_readyRead can also be called from readMoreLater() because we implemented
it so that bandwidth limited reading can be implemented.
This can lead to a race condition if the socket is closing at the specific moment
and then deadlock the channel: It will stay unusable with a zombie request.
The fix in QHttpProtocolaHandler checks if there is actually bytes available to read
from the socket and only then continue.
The fix in the HTTP channel needs to be done to properly finish the reply in
cases of a server replying with HTTP/1.0 or "Connection: close".
The delayed incovation of _q_receiveReply will properly finish up the reply.
Change-Id: I19ce2ae595f91d56386cc7406ccacc9935672b6b
Reviewed-by: Richard J. Moore <rich@kde.org>
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
doc/global/manifest-meta.qdocconf
src/corelib/global/qnamespace.qdoc
src/corelib/io/qstorageinfo_unix.cpp
src/corelib/tools/qtools_p.h
src/sql/drivers/psql/qsql_psql.cpp
Change-Id: I23a15ac84e03ad61d865e3df872b013eb0752949
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a fix-up for cff39fba10ffc10ee4dcfdc66ff6528eb26462d3.
That patch lead to some internal state issues that lead to the QTBUG-47048
or to QNetworkReply objects erroring with "Connection Closed" when
the server closed the Keep-Alive connection.
This patch changes the QNAM socket slot connections to be DirectConnection.
We don't close the socket anymore in slots where it is anyway in a closed state
afterwards. This prevents event/stack recursions.
We also flush QSslSocket/QTcpSocket receive buffers when receiving a disconnect
so that the developer always gets the full decrypted data from the buffers.
[ChangeLog][QtNetwork] Fix HTTP issues with "Unknown Error" and "Connection Closed"
[ChangeLog][QtNetwork][Sockets] Read OS/encrypted read buffers when connection
closed by server.
Change-Id: Ib4d6a2d0d988317e3a5356f36e8dbcee4590beed
Task-number: QTBUG-47048
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|\| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/global/qnamespace.qdoc
src/corelib/io/qwindowspipereader.cpp
src/corelib/io/qwindowspipereader_p.h
src/corelib/statemachine/qstatemachine.cpp
src/corelib/statemachine/qstatemachine_p.h
src/plugins/platforms/xcb/qxcbconnection.h
tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp
tests/auto/tools/qmake/tst_qmake.cpp
tests/manual/touch/main.cpp
Change-Id: I917d694890e79ee3da7d65134b5b085e23e0dd62
|
| |\|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/global/qglobal.h
src/corelib/io/qnoncontiguousbytedevice_p.h
src/gui/image/qjpeghandler.cpp
src/network/access/qhttpthreaddelegate_p.h
tests/auto/corelib/io/qlockfile/tst_qlockfile.cpp
tests/auto/widgets/widgets/qmenubar/BLACKLIST
Change-Id: I01de8c1c28efcedfd7953d05025f54802dc08ab3
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch fixes several upload corruptions if the server closes the connection
while/before we send data into it. They happen inside multiple places in the HTTP
layer and are explained in the comments.
Corruptions are:
* The upload byte device has an in-flight signal with pending upload data, if
it gets reset (because server closes the connection) then the re-send of the
request was sometimes taking this stale in-flight pending upload data.
* Because some signals were DirectConnection and some were QueuedConnection, there
was a chance that a direct signal overtakes a queued signal. The state machine
then sent data down the socket which was buffered there (and sent later) although
it did not match the current state of the state machine when it was actually sent.
* A socket was seen as being able to have requests sent even though it was not
encrypted yet. This relates to the previous corruption where data is stored inside
the socket's buffer and then sent later.
The included auto test produces all fixed corruptions, I detected no regressions
via the other tests.
This code also adds a bit of sanity checking to protect from possible further
problems.
[ChangeLog][QtNetwork] Fix HTTP(s) upload corruption when server closes connection
Change-Id: I54c883925ec897050941498f139c4b523030432e
Reviewed-by: Peter Hartmann <peter-qt@hartmann.tk>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes unnecessary indirect return value and deprecated construction
of QString from QByteArray.
Change-Id: I4b654348285923ac1df39fc03784175ad6acb674
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit adds support for following HTTP redirect responses on a per
request basis.
This behavior is disabled by default. It can be switched on by
setting the QNetworkRequest::FollowRedirectAttribute to true.
2 new error codes have been added to QNetworkReply:
* TooManyRedirectsError: Set when the number of redirects exceed a
given value set by the user (defaults to 50 if not set)
* UnsecureRedirectError: Set when we are redirecting from a 'https'
to 'http' protocol.
Test cases for the following scenarios:
* Single HTTP redirect using local test server
* Changing max-redirects
* Testing all redirect related error scenarios
The next commit will extend this feature at a QNAM level.
Task-number: QTBUG-8232
Change-Id: If9e28ad12bad08bcdc5bc511b1cd59dc9d8150f0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/harfbuzz-ng/harfbuzz-ng.pro
src/gui/image/qimage_conversions.cpp
src/gui/opengl/qopenglextensions_p.h
src/gui/text/qtextengine.cpp
src/network/ssl/qsslsocket_openssl.cpp
src/plugins/platforms/eglfs/qeglfshooks_stub.cpp
src/plugins/platforms/eglfs/qeglfsscreen.cpp
src/plugins/platforms/eglfs/qeglfswindow.cpp
src/plugins/platforms/windows/qwindowsfontdatabase.cpp
src/plugins/platforms/windows/qwindowsfontdatabase_ft.cpp
src/plugins/platforms/windows/qwindowsnativeinterface.cpp
src/plugins/platforms/windows/qwindowsscreen.cpp
src/plugins/platforms/windows/qwindowswindow.cpp
src/plugins/platforms/windows/qwindowswindow.h
src/plugins/platforms/xcb/qxcbdrag.h
src/widgets/itemviews/qabstractitemview.cpp
src/widgets/kernel/qwidget.cpp
src/widgets/util/qsystemtrayicon_p.h
tests/auto/corelib/itemmodels/qsortfilterproxymodel/tst_qsortfilterproxymodel.cpp
Thanks to Friedemann Kleint for resolving the qwindowsfontdatabase.cpp
conflicts.
Change-Id: I937232c30523d5121c195d947d92aec6f129b03e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... but choose HTTP/1.1 and continue connecting anyhow. According to
the NPN spec, actually we should choose SPDY:
"In the event that the client doesn't support any of server's protocols,
or the server doesn't advertise any, it SHOULD select the first protocol
that it supports."
However, some tested servers did not advertise anything and did not
support SPDY, so blindly trying the newest protocol would fail. We are
conservative in that case and choose HTTP.
Task-number: QTBUG-40714
Change-Id: Ia8aaf01fea74e13d9e4416306f85f1890b25559e
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Expose the same kind of TLS PSK client support we already have set
in place for QSslSocket.
[ChangeLog][QtNetwork][QNetworkAccessManager] It is now possible to use
TLS PSK ciphersuites when using HTTPS (or similar protocols working over
SSL).
Change-Id: I56a048e9f4f841f886758c781af2867d18538a3e
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|
|
|
|
|
|
| |
The Qt bug tracker URL changes as part of the qt.io transition
Change-Id: Icb4ab198943b93639b5e3a8d99262303785c6459
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and not only one. This was a problem e.g. when there were several
requests to the same host and the host was not reachable; only one
reply would get an error signal in case we suppressed other errors in
"happy eyeballs" host lookup style.
Task-number: QTBUG-36890
Change-Id: I1b5757498bd644b0d773cf6c43e4950620949c5c
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the only supported SPDY version is 3.0.
The feature needs to be enabled explicitly via
QNetworkRequest::SpdyAllowedAttribute. Whether SPDY actually was used
can be determined via QNetworkRequest::SpdyWasUsedAttribute from a
QNetworkReply once it has been started (i.e. after the encrypted()
signal has been received). Whether SPDY can be used will be
determined during the SSL handshake through the TLS NPN extension
(see separate commit).
The following things from SPDY have not been enabled currently:
* server push is not implemented, it has never been seen in the wild;
in that case we just reject a stream pushed by the server, which is
legit.
* settings are not persisted across SPDY sessions. In practice this
means that the server sends a small message upon session start
telling us e.g. the number of concurrent connections.
* SSL client certificates are not supported.
Task-number: QTBUG-18714
[ChangeLog][QtNetwork] Added support for the SPDY protocol (version
3.0).
Change-Id: I81bbe0495c24ed84e9cf8af3a9dbd63ca1e93d0d
Reviewed-by: Richard J. Moore <rich@kde.org>
|
|
|
|
|
|
|
|
|
|
| |
... to defer the decision which protocol will be used on a specific
channel. This is to allow using the SPDY protocol instead of HTTP (to
be implemented in a later commit); which protocol will be used can
only be decided after the SSL handshake.
Change-Id: I6b538320668fe4994438f0095ecdc445677cf0a6
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
|