To retain backwards compatibility with some QNetworkReply usage,
namely connecting solely to finished-signal and allocating a buffer to
read into, but without storing the entire decompressed file in memory
until read, we may decompress the file twice.
With this patch users can now avoid this double decompression if the
amount of buffered data stays below 10 MiB. This means any file smaller
than 10 MiB will never need to be decompressed twice to know the size of
it. On top of that, if the data is handled as it arrives (e.g. in
readyRead) and the buffer is kept below 10 MiB it won't need to
decompress twice either.
This is active as long as "countDecompressed" is true, though it
currently always is in QNetworkAccessManger, with a future goal to make
it possible to control with public API. Since it requires the user to
potentially adapt their usage of QNetworkReply.
In this patch we also stop tracking the amount of unhandled uncompressed
bytes (uncompressedBytes) in favor of tracking the total amount of bytes
which has been read() by the user of QDecompressHelper (totalBytesRead),
since we can more intuitively work out the total amount of unread bytes
using this value.
Change-Id: Ie3d8d6e39a18343fcf9b610f45c7fe7e4cd4e474
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The actual buffering is performed either in the inner socket (Unix),
or in the pipeReader (Windows). To avoid unnecessary copying of data
between buffers, enforce unbuffered mode for all implementations,
which slightly improves read performance.
Change-Id: Idb2a09f35823b9945c71231710290be12d9930f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This signal is emitted by the QIODevice itself, so we don't have to
forward it from the internal socket.
Pick-to: 6.1 6.2
Change-Id: I85745f36d7a27d92f339a9184de3b6e5d46f6f34
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Before this change, next() was the only way to advance the iterator,
whether the caller was ultimately interested in just the filePath()
(good) or not (bad luck, had to call .fileInfo()).
Add a new function, nextFileInfo(), with returns fileInfo() instead.
Incidentally, the returned object has already been constructed as part
of advance()ing the iterator, so the new function is faster than
next() even if the result is ignored, because we're not calculating a
QString result the caller may not be interested in.
Use the new function around the code.
Fix a couple of cases of next(); fileInfo().filePath() (just use
next()'s return value) as a drive-by.
[ChangeLog][QtCore][QDirIterator] Added nextFileInfo(), which is like
next(), but returns fileInfo() instead of filePath().
Change-Id: I601220575961169b44139fc55b9eae6c3197afb4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Ditto QNetworkAccessAuthenticationManager.
QSharedPointer performs twice as many atomic operations per pointer
copy as std::shared_ptr, and this is private API, we're not bound by
BC constraints, so we can port to the more efficient version.
Change-Id: I59dc09ff4eb3b4acf5d7a68695752a9a7110d8d3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Unix sockets do not suffer from SYN flood, thus the hardcoded value to
50 is size of the only queue to hold connections to be accepted,
resulting in dropped connections when the limit is reached.
On Windows the hardcoded value is 8, this patch changes the default to
50 matching UNIX.
[ChangeLog][QtNetwork][QLocalServer] Added setListenBacklogSize() to
be able to have control over the listen backlog feature.
Change-Id: Iaee6349a46b75b0bd05e40e7ade5948f1cf9f407
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This introduces a new attribute that allows behavior to keep
the TCP connection(s) to a HTTP1/HTTP2 host longer or shorter
than the default of 120 seconds.
Note that the server might still close the connection earlier.
Fixes: QTBUG-20726
Fixes: QTBUG-91440
Change-Id: I7da64230a78c642c12c0ddbe6b678cf17c3aafde
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This mechanism was neither properly designed nor correctly tested
initially on Windows.
[ChangeLog][QtNetwork][Important Behavior Changes] QLocalSocket on
Windows now implements delayed closing, which is consistent with
the behavior on Unix.
Change-Id: Ic3bc427e68eea7f18201f6129df19fbc87d68101
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
It's the user's privilege to do so when they want to finish reading the
QIODevice. Moreover, this is the only difference between close() and
disconnectFromServer().
[ChangeLog][QtNetwork][Important Behavior Changes] The Windows
implementation of QLocalSocket::disconnectFromServer() no longer calls
close(), which is consistent with the behavior on Unix.
Change-Id: Ie9ce20c60259a2b08f5254b719355bd7be9b17cd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
In the case where we have pending data to write, calling flush() here
may cause the device to close immediately, if the pipe writer already
got a result of the last operation from the thread pool. In this
scenario, the device does not enter the 'Closing' state, which leads
the following code to unexpectedly fail on Windows
socket.write(...);
socket.disconnectFromServer();
QVERIFY(socket.waitForDisconnected());
Removing the call to flush() makes the behavior consistent with the
implementation on Unix.
Change-Id: Ic31fbc999be979c1e5befa8f132d9fb367f472ca
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The QLocalSocket destructor should immediately close the connection
and destroy the socket, clearing any pending data in the write buffer.
The abort() call ensures that the pipe is destroyed on Windows, making
the additional call to destroyPipeHandles() from the private destructor
unnecessary.
Change-Id: Ic7a0d8cf2779cd933cded864c8bab0d096469499
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The _q_pipeClosed() slot unconditionally removes the pipeWriter just
before closing the pipe. Thus, if we have an invalid handle here,
the pipe writer has already been destroyed anyway.
Change-Id: I57463d8464afe6141c21a63851a56ebddabd3f13
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
According to the documentation, calling abort() should immediately
reset the socket to its initial state. This includes:
- closing the file descriptor;
- closing the QLocalSocket as an I/O device;
- canceling a pending outgoing connection, if it exist;
- reseting 'serverName' string.
So, adding a call to close() resets the state entirely.
Pick-to: 6.1 6.2
Change-Id: I9c604b5187c6300b437d7aa4c2d06db03edacf21
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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>
If the file already existed we simply removed the old one without
adjusting the size. So use the removeFile() function which takes care of
that.
Additionally, if the current size was non-null we previously increased
the size (presumably meant to be temporarily but wasn't) and called
expire() which would either:
1. not do anything and return currentCacheSize, if it was not greater
than the max size. This would mean that the size of the file would be
counted twice.
or,
2. discard currentCacheSize, measure the size of the items, and then
remove some items if the total size surpassed the max cache size
Neither of those branches need us to (temporarily) increase
currentCacheSize. It also doesn't attain the (presumed) goal of trying
to keep below the max cache size after having added the new item.
Fixes: QTBUG-95009
Pick-to: 6.2 6.1 5.15
Change-Id: I2b5b13ff473a7aa8169cf2aecfea783c97f2d09a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Qt has a hardcoded backlog value of 50,
this allows for applications to tune this
value. Modern kernels have the SYN cookie
feature that reduces pressure from an
flood attack, the backlog setting however
is then a queue for most likely real
completed (SYN/ACK) connections hence, it's
easy to get clients connections dropped
with this very small limit.
[ChangeLog][QtNetwork][QTcpServer] Added
QTcpServer::setListenBacklog() to be able
to have control over the listen backlog feature.
Change-Id: I1c78af6d99e012591e214b7e09fa85c485880d48
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
... instead of QSharedPointer.
QSharedPointer performs twice as many atomic operations per pointer
copy as std::shared_ptr, and this is private API, we're not bound by
BC constraints, so we can port to the more efficient version.
Change-Id: I2e2a02493565a7ca51c86ec0ed66b6ce7c763e41
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In preparation of porting to shared_ptr.
Add a few strategic moves and remove a rather pointless comment
stating the obvious.
Change-Id: Ie1c0f3431af79bdb204e00d99323bf9f2d100d0d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The maximum size for a hash result is 64 atm. Even if, and esp when,
we'll get to 128 and 256 bytes in the future, there's no reason to use
dynamic memory, because the sizes will always be statically known.
So use, essentially, a std::array<char, 64> to hold the result
internally. Add a bit of convenience API on top to limit impact on the
rest of the code and add a few static_asserts that ensure this is large
enough. Then give users access to the internal buffer by adding
QByteArrayView resultView() const noexcept. The documentation snippet
is taken from QString::data(), suitably adjusted.
Use resultView() in a few places instead of result().
[ChangeLog][QtCore][QCryptographicHash] Changed to use a
statically-sized buffer internally. Added resultView() to access it.
Change-Id: I96c35e55acacbe94529446d720c18325273ffd2f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
... instead of QSharedPointer.
QSharedPointer performs twice as many atomic operations per pointer
copy as std::shared_ptr, and this is private API, we're not bound by
BC constraints, so we can port to the more efficient version.
Change-Id: I9572a8321aae381e5dbe4a51119f2c9494a8fbc7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Both readChannelFinished() and disconnected() signals should be emitted
after closing the pipe. Otherwise, these signals do not correspond to
the state of the socket and may even be resent, if a slot connected to
one of these signals processes events.
[ChangeLog][QtNetwork][Important Behavior Changes] QLocalSocket on
Windows now emits both readChannelFinished() and disconnected() signals
after closing the pipe and emitting stateChanged(UnconnectedState),
which is consistent with the behavior on Unix.
Pick-to: 6.2
Change-Id: I1cc551b7897fdba3cec1fd6705f5396790818c7d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The \sa was neglected
Amends d33040548f
Pick-to: 6.2
Change-Id: Ib298ac3390819f9ea4092a1f2bf470ea82c9e4fe
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Use QByteArray::fromRawData() and QList::fromReadOnlyData() to return
the QList<QByteArray> without allocating memory.
Change-Id: Iefa3250ea2acc79df92400d2d225e450566477e2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The base implementation discards the data by reading into a dummy
buffer, which is slower than necessary.
Change-Id: Iabf0c4a25746af6cac5b61d7bda66d89501c808c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
... instead of the "usual" rule of three: ctor, addData(), result().
Not only does it generate less code in the caller, it's now also
faster.
Change-Id: I67c7eeb01f527b90e80a08f60c1c7f2ec1e49dd4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The base implementation reads data using repeated calls to getChar(),
which is quite slow.
Change-Id: Ie46624df63791b2cdd3c8a28fe3327427d942505
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Incl. the static hash() function. Remove the QByteArray versions from
the API, but not the ABI.
Adapt some callers.
[ChangeLog][QtCore][QCryptographicHash] Replaced QByteArray with
QByteArrayView in addData() and static hash() functions.
Change-Id: Ia0e9bf726276305e05894d323d76a29e985f39eb
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
To (set)decompressedSafetyCheckThreshold, as suggested on the API review.
Task-number: QTBUG-94407
Change-Id: Iffc52691022939ae46703de8a0416355487b716f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Replace the hardcoded cpp exports with a generated one where it's
applicable.
Task-number: QTBUG-90492
Change-Id: Idc160b594987b2c765e75bd669aae851b4366282
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As per the best practice laid forth in RFC-8996.
TLS 1.2 was recommended from 2008 until TLS 1.3 was released in 2018.
[ChangeLog][QtNetwork][QSslSocket] TLS 1.0, 1.1 and DTLS 1.0 are now
deprecated, as recommended by RFC-8996.
Fixes: QTBUG-92880
Change-Id: I90cebcfb07cfce623af7ac9f2b66ce9d02586b54
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Triggered by API review in Gerrit patch 355960.
Task-number: QTBUG-94407
Pick-to: 6.2
Change-Id: I7cafc1cc9d4b929040b53c6bf92c91d73c3b39f2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Found by clang 12:
qsctpsocket.cpp:172:56: error: result of comparison of constant 9223372036854775782 with expression of type 'int' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
Q_ASSERT((datagramSize + int(bytesToRead)) < MaxByteArraySize);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~
Change-Id: I7246c3e7bb894e0d9521fffd168af11764956d8f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Replacing a call to waitForWrite(0) with checkForWrite() changes
nothing in logic, but saves one system call. As a result, unused
functions in the QWindowsPipeWriter class have been removed.
Change-Id: I34ec6310d9659f59a720056b9be54e31f2193116
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Remove the configure.json and configure.pri files that
were used for the qmake-based configure.
Remove the .prev_*.cmake files that were a by-product of
configurejson2cmake.py.
Pick-to: 6.2
Task-number: QTBUG-89536
Change-Id: Ie827562f7fd2513d59f69234d77b8b93124ea78e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Also, a minor clean-up: isMatchingHostname() overload
was never used, deleted (and it could not be used safely,
since it requires the name to be normalized first).
The file (qtlsbackend.cpp) was re-shuffled, to have
backend on top of the classes which this backend
is factory for.
Pick-to: 6.2
Pick-to: 6.1
Fixes: QTBUG-91929
Change-Id: I435c69b167f57f7c3f76e34449c52f665dc6f7c2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's no longer used today.
And while we're at it: delete or fix typos in some nearby comments
Change-Id: Ib52268eeb936e71d6c09aece2e0833b99309ef2d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
SETTINGS for max concurrect number of streams is 'one direction' - this
is how our peer conveys the possible number of streams _we_ can open,
not _them_. If they choose to have it unlimited - let it be so.
It's possible to send 0 as maximum number, also, it's possible to
reduce the maximum compared to initial at some point - then I have
to avoid integer overflows.
Pick-to: 6.2
Pick-to: 6.1
Pick-to: 5.15
Fixes: QTBUG-94470
Change-Id: Ia02247acbaedd70998a4cab02082ba10f45cf78c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
