| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
+ a small stretch into adjacent functions, because some are used from
the protocol handler(s).
Task-number: QTBUG-102855
Change-Id: Ie394378fef2b1723e69286fd870fc34b7306734a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make QNetworkAccessManager to discard all informational (1xx) replies
from HTTP servers with the exception of 101.
According to RFC 9110:
"A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one.
A user agent MAY ignore unexpected 1xx responses."
Status code 101 is an exception because we use it to upgrade to http2
cleartext when it is enabled.
Fixes: QTBUG-108068
Change-Id: I415ff053180a43f0c7ff1b4b2a60fd114ce08ac9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
|
|
|
|
|
| |
Change-Id: I132533b9bc1f2b4d66f94599efb04def571cd2ff
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qExchange is one of the few remaining functionalities that have not been
moved out of qglobal. Given that std::exchange exists in the standard, we
can simply move to it everywhere...
...if it weren't for the fact that std::exchange is only constexpr in
C++20, and only has its noexceptness specified in (most likely) C++23.
Still, we want to move to the existing std functionality where
possible, to allow the removal of qglobal includes in lieu of something
more fine-grained in the future.
So leave any constexpr calls[1] alone for now (and observe that none of
our current usages cares about the conditional noexceptness), but
replace everything else.
[1] QScopedValueRollback' ctor and QExplicitlySharedDataPointerV2::take
Task-number: QTBUG-99313
Change-Id: I599cb9846cf319c7ffd3457130938347a75aad25
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-98434
Change-Id: Ic235b92377203f7a1429ae7fd784c4a1fa893e9f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Moved to after the header is actually written, not just generated.
For requests with data (put/post) we may have to wait for a callback
before the data to write is available. Since we then delay writing the
header as well it would be disingenuous to emit requestSent().
Pick-to: 6.3
Change-Id: I76c2d40ca48faaa1f6730ce8b3d5a8a4c3156f8f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-80701
Change-Id: I43f5e102c15d121dba74e07e3cd4bb8aded1c763
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
These signals allow monitoring where in the HTTP1/HTTP2
flow a request is currently in.
Fixes: QTBUG-71698
Fixes: QTBUG-18766
Change-Id: Icc2fe435afc9f680fa7a76c32731e25fcdfeb4b4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than when the data is received. Source compatibility is
achieved through double-decompressing the data. This lets us know
how many bytes are available just as before but without having the
uncompressed data left in memory.
Fixes: QTBUG-83269
Change-Id: I352bd09581614c582e4628243e2a0e895ba4946b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
| |
Change-Id: Ia3fb2e2c185f4e61234ce237416028b0c45357f8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For HTTP connections, QNAM defaults to opening its TCP socket in
unbuffered mode. This means that Qt will send the data written
into the socket right to the kernel, queueing only if the kernel
says it doesn't want more data for the moment being.
QNAM itself then uses separate write() calls to write the HTTP
headers and the body of the request (like POST or PUT). These 2+
writes result in headers and body being sent over different TCP
segments -- even if, in principle, a POST with a few bytes of data
(e.g. a HTML form, or a REST or SOAP request) could fit in the same
segment as the request.
Multiple writes like this interact extremely poorly with other
TCP features, e.g. delayed ACKs, Nagle's algorithm and the like.
In a typical scenario, the kernel will send a segment containing just
the headers, wait for the ACK (which may be delayed), and only then
send the body (it wasn't sent before because Nagle was blocking it).
The reply at this point is immediate (because the server can process
the request and starts replying), but the delayed ACK is typically
40-50ms, and documented up to 500ms (!). If one uses QNAM to access a
service, this introduces unacceptable latency.
These multiple writes to the OS should be avoided.
The first thing that comes into mind is to use buffered sockets.
Now, there are good reasons to keep the socket unbuffered, so we
don't want to change that. But the deal breaker is that even buffered
sockets won't help in general: for instance, on Windows, a buffered
write will immediately detect that the socket is ready for write and
flush the buffer right away (not 100% sure of why this is necessary;
basically, after populating the QTcpSocket write buffer, Qt enables
a write socket notifier on the socket -- notifier that fires
synchronously and immediately, without even returning to the event
loop, and that causes the write buffer flush).
Linux of course offers the perfect solution: corking the socket via
TCP_CORK, which tells the kernel not to send the data right away but
to buffer it up to a timeout (or when the option gets disabled
again, whichever comes first). It's explicitly designed to support
the case of sending headers followed by something like a
sendfile(2). Setting this socket option moves the problem to
the kernel and we could happily keep issuing multiple writes.
Ça va sans dire, no other OS supports that option or any other
similar option.
We have therefore to deal with this in userspace: don't write in the
socket multiple times, but try and coalesce the write of the headers
with the writing of the data. This patch implements that, by storing
the headers and sending them together with the very first chunk of
data. If the data is small enough, this sends the entire request
in one TCP segment.
Interestingly enough, QNAM has a call setting TCP_NODELAY
currently commented out because Qt doesn't combine "HTTP requests"
(whatever that means). The call comes all the way back
from pre-public history (before 2011) (!). This patch doesn't
touch it.
Fixes: QTBUG-41907
Change-Id: Id555d14e0702c9f75c3134b18277692eb3659afe
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 94b3dd77f29a00ebbd1efdc66d75f57e1c75b152.
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: I0dd60cf1ae9d1bd95beeb8ad58661ca4b1fb63b9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
Move away from using 0 as pointer literal.
Done using clang-tidy. This is not complete as
run-clang-tidy can't handle all of qtbase in one go.
Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Exclude QHttp(Multi)Part from being built if http is disabled, and
replace the exclusion macros. Use the qmake project files to exclude
source files, and QT_REQUIRE_CONFIG(http) in headers.
Change-Id: I432fa3c78aa97b5ed2eb1027ac1dc3bdb134f9ba
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/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>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
|
... 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>
|