Because we will do a small wait after the final connection (to see
if there are any unexpected extra connections) we can save some time
by reducing _how long_ we wait for it.
In general we only need an extra long wait for the first connection,
subsequent connections are faster.
So we change the loop structure from looping until we hit 20(!)
connections, when anything larger than 6 will fail the test anyway!
And use qWaitFor instead of repeatedly calling enterLoop and checking
the state of an ElapsedTimer, the total wait time is not super
interesting, and made it a guarantee that the test would take 10
seconds.
While we are here, update the attribute we use to test HTTP/2
connections. We were previously enabling http/2, but this is the new
default so it's not needed. We do, however, need to enable h2c if we
want to see it trying to upgrade to http/2 over cleartext.
Not a big issue, so we don't pick it very far back.
Pick-to: 6.7
Change-Id: Ia314ae2827ab8a8baaa4af2c5136c5e531bcb1f8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There were a few issues to deal with. One of them was that we would
print a warning about an internal error if we tried to *set* an error
on the reply after it had been cancelled. That's kind of unavoidable
since these things happen in different threads, so just ignore the
error if we have been cancelled.
The other issue was that, for a request with data, we will buffer the
data to send, and _only then_ do we start the request. This happens
asynchronously, so the user can abort the request before it has finished
buffering. Once it finished buffering it would set the state of the
request to "Working", ignoring that it was already marked "Finished".
Fixes: QTBUG-118209
Fixes: QTBUG-36127
Pick-to: 6.7 6.6
Change-Id: Idbf1fd8a80530d802bee04c4b0a6783cba4992d3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The function replaces one of the found entries with the new value,
and removes any other entries. If no entries are found, a new entry
will be appended. The replacement search is done for performance
reasons; it's cheaper to replace an existing value.
All in all the function is a more convenient and performant
alternative for this sequence (which proved to be common while
porting QtNetwork internals to QHttpHeaders):
header.removeAll(<headername>);
header.append(<headername>, <value>);
[ChangeLog][QtNetwork][QHttpHeaders] Added replaceOrAppend()
convenience method, which either replaces previous entries with
a single entry, or appends a new one if no entries existed
Fixes: QTBUG-122175
Change-Id: I03957645d7e916a732ac7b8d3ae724bb6b16af87
Reviewed-by: Lena Biliaieva <lena.biliaieva@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Make QHttp2ProtocolHandler discard all informational (1xx) replies 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."
Fixes: QTBUG-121755
Change-Id: I8b8d578f23d4fbe28929f8c54b3607bcaf85405f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
The "HTTP RFC 9110 5.3 Field Order" states that the values combined
with comma can be followed up by an optional whitespace, and for
consistency recommends "comma SP". This is also what eg. 'MDN Web
Headers' class does.
Fixes: QTBUG-122650
Pick-to: 6.7
Change-Id: I3391c86018090f0b8721929b64a7e3029e98ac85
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The test is a bit silly, it was originally written to make sure that
we produce meaningful errors when trying to connect to a proxy server
where the connection is refused or the server doesn't respond at all.
To test that, it creates a local QTcpServer and starts listening to any
free port (by specifying port 0) and then it closed the server and
uses the address-port of localhost:serverPort as the proxy to use, since
we know it _was_ unused, since we were able to bind to it.
However, just calling close() doesn't immediately tear down the internal
socket descriptor, so the OS may still have the port reserved for
some time.
By moving the QTcpServer to a narrower scope we will quickly destroy it
and the internal socket engine, which is parented to the server, and
this in turn releases the socket descriptor.
Pick-to: 6.7 6.6 6.5
Change-Id: If12128fc21d1f545df152f08f0d52c1b14ac6037
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
To enable setting a default priority for all requests to a given site.
Fixes: QTBUG-121669
Change-Id: Icd8a9c59e4afb0432c65f84cc8115ae0c7f85506
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
1XX statuses are not final statuses, and testing 'error' on it is not
necessarily very meaningful. Furthermore the internal handling of
these statuses changes in Qt 6.8.
Fixes: QTBUG-108068
Pick-to: 6.7
Change-Id: I9c18c579cd310266273eccd2aee2e032f60538e0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
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>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Instead of separate QJsonObject and QJsonArray types.
Resulted from API-review
Pick-to: 6.7
Change-Id: I977d692d3709a8c3aa872683ddda54a143c25e67
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This naming should make it clearer that (successful) calls to
readJson(), readBody(), and readText() consume the data received
so far.
Resulted from API-review
Pick-to: 6.7
Change-Id: I09ca9eac598f8fc83eecb72c22431ac35b966bf5
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Note: documentation will be updated in a follow-up commit
This commit makes QRestReply and QRestAccessManager
classes lighter, non-owning wrappers. Furthermore their
APIs don't duplicate the wrapped QNetwork* APIs.
This makes it easier to use / opt-in to these helpers
in pre-existing applications which are based on
QNetworkAccessManager and QNetworkReply.
Since APIs are no longer duplicated, the QRest
classes are more obviously a convenience _wrapper_,
as opposed to being an alternative vertical stack.
In practice this change consists of:
- QRestAM never instantiates QNetworkAccessManager,
but accepts it via constructor. It does not take
ownership of the QNetworkAccessManager.
- QRestReply accepts QNetworkReply via constructor. It
does not take ownership of the QNetworkReply
- Signals and most duplicated functions are removed
from both QRestAM and QRR.
- QRestReply is no longer a QObject
- Since QRestAM doesn't have much to report anymore,
the debug operator is dropped.
Resulted from API-review
Pick-to: 6.7
Change-Id: Ib62d9cc2df41cac631396a84bb7ec4d2d54b0c8c
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Version 883ced078a83f9d79a98933145425c221a5e51f0, fetched on
2024-01-25.
[ChangeLog][Third-Party Code] Updated the public suffix list to upstream
SHA 883ced078a83f9d79a98933145425c221a5e51f0.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Task-number: QTBUG-121325
Change-Id: I95e82b5c351218c1641e11e7a166ae21be2c5ad6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The code did not handle the path where we didn't have a challenge.
We cannot recover from that so we just have to fail the request.
Amends fe1b668861
Pick-to: 6.7 6.6 6.6.2 6.5 6.2
Fixes: QTBUG-121515
Change-Id: Ie39a92e7439785a09cad28e8f81599a51de5e27f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
QHttpHeaderParser::headers() method is changed to return QHttpHeaders.
QAuthenticatorPrivate::parseHttpResponse() method is changed to work with QHttpHeaders.
QHttpNetworkHeader::header() method is updated to return QHttpHeaders.
Tests are updated.
Task-number: QTBUG-120133
Change-Id: I20a18b509acd7a8b8d93884cff8349519d64293e
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Øystein Heskestad <oystein.heskestad@qt.io>
We need a way for users to consume the complete contents of
QHttpHeaders.
Until now, the only way was
for (const auto &name : h.names())
use(h.value/combinedValue(name));
which is quadratic.
Adding the usual iterators and operator[] would require us to
expose the underlying value_type, which we're not ready to do, yet.
So we added nameAt() and valueAt() functions in previous commits to
enable efficient indexed iteration without the need to expose a
value_type. Having added those, we can now remove names(), which had
the wrong value_type (QByteArrays are by definition UTF-8 in Qt, while
header names are L1), and is no longer needed to facilitate iteration.
In QNetworkRequestFactory, temporarily use toMultiMap() because we
need the combinedValue() of all headers here. The fix will be to make
QNetworkRequest QHttpHeaders-aware, but that's a Qt 6.8 thing, even
though we should still de-pessimize this code for Qt 6.7 with private
API.
Resulted from API-review.
Pick-to: 6.7
Change-Id: I65086ef4c62e22554ae7325a846bebc08b44916f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
We need a way for users to consume the complete contents of
QHttpHeaders.
For now, the only way is
for (const auto &name : h.names())
use(h.value/combinedValue(name));
which is quadratic.
Adding the usual iterators and operator[] would require us to
expose the underlying value_type, which we're not ready to do, yet.
So add nameAt() and (in a previous commit) valueAt() functions to
enable efficient indexed iteration without the need to expose a
value_type.
Return by QLatin1StringView, not QAnyStringView, because that
statically encodes the actual encoding used (and required by HTTP
specs and promised by the class documentation, so it won't need to
change). For the setters, we want to be accomodating QString,
QByteArray, etc, which is why those take QAnyStringView.
Resulted from API-review.
Pick-to: 6.7
Change-Id: I0153c5aad0f6260b5dbc963de0aaf4ef42fdd4f1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
We need a way for users to consume the complete contents of
QHttpHeaders.
For now, the only way is
for (const auto &name : h.names())
use(h.value/combinedValue(name));
which is quadratic.
Adding the usual iterators and operator[] would require us to
expose the underlying value_type, which we're not ready to do, yet.
So add valueAt() and (in a follow-up) nameAt() functions to enable
efficient indexed iteration without the need to expose a value_type.
Resulted from API-review
Pick-to: 6.7
Change-Id: I863f59618cea5682386ce26b66b4b1655eac7950
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
A QMultiMap is used, while only qset.h is included.
FTBFS w/o precompiled headers.
Include qmap.h as well.
Pick-to: 6.7 6.6 6.5
Change-Id: I5f6e1d204bfa94cc6a81f6883c7a7b0ee1e9963c
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
For use in QtGRPC.
There is some duplication between this code and the code in
QHttp2ProtocolHandler. But let's not change the implementation of
the protocol handler after the 6.7 beta release. Nor do I think we
should do it for 6.8 LTS. So let's just live with the duplication
until that has branched.
Pick-to: 6.7
Fixes: QTBUG-105491
Change-Id: I69aa38a3c341347e702f9c07c27287aee38a16f2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
There's several ways to compare HTTP headers, and arguably
the need for it is not very high. For the time being users can use
different accessors and compare in ways that make sense for
their use cases.
Consequently since HTTP headers are no longer trivially comparable,
it makes also comparing the request factories more 'moot' because
headers are a central piece of request information. So removed
comparison from request factory as well.
These comparisons can be restored later if a clear understanding
on it's need, and on how it should be best done, emerges.
Resulted from API-review
Pick-to: 6.7
Change-Id: Idb5ab3710268b52a8e59656db8cc7de82f0ae511
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The json return type and function naming has gone back
and forth. Let's go with QJsonDocument after all, and add new
overloads in future if necessary.
Pick-to: 6.7
Task-number: QTBUG-119002
Change-Id: I3f9de0e6cba7d5c52d016d252d65b81f345af050
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Provides the possibility to read text data as it arrives, instead
of needing to wait until the whole body is received.
Pick-to: 6.7
Task-number: QTBUG-119002
Change-Id: I64f90148fd41a77c4ae2d5dbd6194a924a9f3a86
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The vast majority of header fields appear only once, but there was no
efficient way to get that value: values() returns as a
QList<QByteArray> (allocating) while combinedValue() returns a
QByteArray constructed from values().join() (also allocating).
It follows that the QHttpHeaders API is incomplete (lacks an efficient
basis of operations in EoP terms).
Add a value() function that returns either the value or a
user-provided fall-back as a QByteArrayView. Unlike values() and
combinedValue(), this function can be noexcept, greatly improving
codegen for callers.
Found in API review.
Pick-to: 6.7
Task-number: QTBUG-107042
Change-Id: I2da20815fd46fdd7f150c224f41eee53abed313e
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Clean up the C'n'P in the test a bit before adding tests of new
functions.
Pick-to: 6.7
Task-number: QTBUG-107042
Change-Id: I2da20815fd46fdd7f150c224f41eee53abed313d
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It is somewhat common HTTP method with RESTful use cases
(partial updates on resources)
Task-number: QTBUG-114637
Change-Id: Id252d3f4b54c3ebb8df5c93259e64a4af2d0ca2f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Added to both QNetworkRequestFactory and QRestAccessManager
Task-number: QTBUG-114717
Change-Id: Ibca55bba548a034a0da7ea60550642c150b63dc2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Provide users with means to use more modern time/duration type.
Please note that since QTimer does not currently support
timeouts larger than 'int' milliseconds, the limit on how long
durations can be expressed, remains. This should not
be an issue in practice with network requests, as a typical
int32 system can express timeouts of ~24 days.
[ChangeLog][QtNetwork][QNetworkAccessManager] Add std::chrono
support for transfer timeout.
[ChangeLog][QtNetwork][QNetworkRequest] Add std::chrono support
for transfer timeout.
Fixes: QTBUG-118714
Change-Id: If85678a5994c59bac5926e47f98c9cfeb2a07c30
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
These include:
- readyRead(), signal for indicating new data availability
- bytesAvailable(), function for checking available data amount
- downloadProgress(), signal for monitoring download progress
Task-number: QTBUG-114717
Change-Id: Id6c49530d7857f5c76bd111eba84525137294ea7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The class provides a way to represent server-side service endpoints.
With RESTful applications these endpoints typically have a need for
repeating requests fields such as headers, query parameters,
bearer token, base URL, SSL configuration. This class allows setting
of the repeating parts, while allowing the setting of changing parts
on a per-request basis.
[ChangeLog][QtNetwork][QNetworkRequestFactory] Added a new convenience
class to help with the needs of repeating network request details
imposed by the server-side service endpoints, which is common
with RESTful applications.
Task-number: QTBUG-113814
Change-Id: Iabcfaed786949ffbb0ad0c75297d0db6ecc1a3cc
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
New QHttpHeaders class for use in place of
std::pair<QBA,QBA>, QMap<QBA>, and QMultiMap/Hash<QBA,QBA>
to represent HTTP headers.
[ChangeLog][QtNetwork][QHttpHeaders] New QHttpHeaders class
Task-number: QTBUG-107042
Change-Id: I54766886a491acfc9a813a3414322a75011acb9d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
It fails frequently. Might have to blacklist the entire test case, or
even skip when running on qemu, if this doesn't help.
Task-number: QTBUG-119616
Pick-to: 6.6
Change-Id: I446612c0fb5b2afc021aeb2fab9be010ac071acd
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Make sure the reply is marked as finished and that the body is received
even if we didn't succeed.
In a real scenario that would include some text like Access Denied.
Also, no longer clear() the authenticationHeader in the server, since
that meant the server would not send the header again if the client
failed to authenticate. Luckily this wasn't actually causing any
problems before, since we only tested the expected www-authenticate
header.
As a drive-by: clang-tidy complained about not using const-ref for a
lambda.
Pick-to: 6.6 6.5 6.2
Change-Id: Ia4452fff7d9370d7d460433257d84eff0a6f469b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add two overloads to QNetworkAccessManager to support GET requests
with body.
Modify QNetworkReplyHttpImpl as well as these requests should not
be cached.
If the request is redirected it is possible that its type changes
from POST/PUT to GET and in this case the message body is deleted.
However, if a GET request has a body it should keep it after it has
been redirected - modify QNetworkReplyHttpImpl to keep the message
body after it has been redirected.
Fixes: QTBUG-112871
Change-Id: Ib01898638ed94238a98291870a5c51d56030868a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Juha Vuolle <juha.vuolle@qt.io>
We were using the .remove(Key) API on the map instead of
erase(iterator), so we were removing any reply of the same priority that
had not yet been popped from the queues.
Rewrote to drop loop and only work with iterators.
This issue was there since SPDY days, so not picking all the way back to
5.15, where HTTP2 anyway is not enabled by default.
As a drive-by, drop the #ifndef QT_NO_SSL, which was also there from
SPDY times, which was TLS-only.
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-116167
Change-Id: Id7e1eb311e009b86054c1fe3d049c760d711a18a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Alexandru Croitor
Mårten Nordheim
Juha Vuolle
Matthias Rauter
Mate Barany
Lucie Gérard
Lena Biliaieva
Axel Spoerl
Marc Mutz
Volker Hilsheimer