Since commit f30641a7 is has been possible to issue more than one host
lookup request per HttpNetworkConnection. If the result was both an
IPv4 and IPv6 address, and we get a second similar DNS reply, we
end up triggering the assert in startNetworkLayerStateLookup().
This patch splits the InProgress state to HostLookupPending and the state
of trying both IPv4 and IPv6. This makes it possible to ignore any new DNS
replies received after the first succesfull one.
Change-Id: I0b8d6b1582fdaed69dde5926019b60bb0cbd580d
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Sometimes the signal QNetworkReply::error(QNetworkReply::NetworkError)
is not emitted for certain requests.
This happens under the following conditions:
* The hostname provided in the request is incorrect, i.e it will
result in a DNS lookup failure.
* There is a previous request, for the _same_ host, already pending.
The first request that comes for the (incorrect hostname) url, gets
enqueued via QHttpNetworkConnectionPrivate::queueRequest(). Here,
after starting a DNS lookup, we mark the network state of this
connection as - "InProgress".
Now, if a second reuest comes for the same host, we use the existing
HTTP connection object as it's present in the cache. However, when
enqueing the request (in queueRequest()), we see that the network is
NOT in "Unknown" state and return immediately without adding this new
request to the list of pending lookups (via QHostInfo::lookupHost()).
To fix this issue, we should queue incoming lookup requests, even if
the current (HTTP) connection is in the "InProgress" state, so that we
can inform the requestor of a failed lookup. Since
QHostInfo::lookupHost() handles lookups for duplicate hostnames
properly, things should be fine even if multiple requests for the same
host have been enqueued.
Task-number: QTBUG-32911
Change-Id: I6a9c8430121e9a5a2d45983b6bda70c324437992
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
We currently always generate our own Authorization header, which
overrides any Authorization headers set the by user application.
Change-Id: I3b11c8dd0bc708e795ff697262a383ce28cae2f3
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Default for QUrl::password() and QUrl::userName() is in Qt 5.1 QUrl::PrettyDecoded
which means the return value may contain percent-encodings. For authentication
we need the real decoded result, and should instead use QUrl::FullyDecoded.
Note this bug has already been fixed indirectly in Qt 5.2 since the default for the
two methods was changed to QUrl::FullyDecoded.
Change-Id: Ia0f38c073cb001e37ad8b3eda40b3db756bec3dc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The check is bogus anyway. It was bogus when it was added. The bug is
not because of "GCC on IRIX", it's simply a GCC bug and was probably
tied to some GCC versions. It should have been reported and followed up.
I don't even remember what GCC versions we had on the IRIX machines
(plastkrakk, I can't remember the other two machine names). But I could
bet they were GCC 3.4 or 4.0.
Change-Id: I84ce4e1ad68bb0520b63c210f841e0c604dbd03a
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
When readData() is called repeatedly, we need to keep track which
part of the multipart message we are currently reading from.
Hereby we also need to take the boundary size into account, and not
only the size of the multipart; otherwise we would skip a not
completely read part. This would then later lead to advancing the
read pointer by negative indexes and data loss.
Task-number: QTBUG-32534
Change-Id: Ibb6dff16adaf4ea67181d23d1d0c8459e33a0ed0
Reviewed-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
We were not comparing all fields.
Spotted-by: Richard J. Moore <rich@kde.org>
Change-Id: I5c1a773b00b64a26606c47ced292808696c9b4bb
Reviewed-by: Richard J. Moore <rich@kde.org>
Each pair of (normal request, preconnect request) requires only one
socket. E.g. if there is 1 preconnect request in-flight and 2 normal
requests, we need only 2 sockets in total, and not 3.
Therefore, we need to keep track of whether a request is
preconnecting or a normal one.
Task-number: QTBUG-31594
Change-Id: If92ccc35abadfa6090d64ee92bd466615909c94c
Reviewed-by: Richard J. Moore <rich@kde.org>
We do not decide which socket a HTTP request is sent on until the
socket is actually ready for sending a request (i.e. it is connected
for HTTP requests and encryption is done for HTTPS requests).
When deciding how many sockets we need for the queued requests, we
consider an in-flight socket as free if it is still connecting.
However, we considered a socket that was connected but needed to
complete encryption as busy, and would instead open another socket.
Now, we consider an encrypting socket as in-flight as well.
Change-Id: I93d6743da6fc430d1424c6965e1475865fd97243
Reviewed-by: Richard J. Moore <rich@kde.org>
It is deprecated and clang is starting to warn about it.
Patch mostly generated by clang itself, with some careful grep
and sed for the platform-specific parts.
Change-Id: I8058e6db0f1b41b33a9e8f17a712739159982450
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... because otherwise this would crash.
Apparently there are cases where the header name is empty.
Task-number: QTBUG-31667
Change-Id: I31b3e964502c05b7614c23876bb3752fa75ab22d
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
If an app knows it needs to connect to a host beforehand, it can "warm up" the
connection cache by making DNS lookup, TCP (and if needed SSL) handshake before
the actual HTTP request is sent. When the HTTP request is made, it will be
considerably faster when there is already a working connection.
Here are some typical results from the benchmark:
* Linux desktop with Ethernet:
"http://www.google.com" full request: 279 ms, pre-connect request: 61 ms,
difference: 218 ms
"https://www.google.com" full request: 344 ms, pre-connect request: 60 ms,
difference: 284 ms
* mobile device (BlackBerry 10) with Wifi:
"https://www.google.com" full request: 898 ms, pre-connect request: 159 ms,
difference: 739 ms
"http://www.google.com" full request: 707 ms, pre-connect request: 200 ms,
difference: 507 ms
Task-number: QTBUG-30771
Change-Id: I3566b7f08216ab93a39e2024ae7d1ceb7ae21891
Reviewed-by: Jonas Gastal <gastal@intel.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
All occurrences of `#if defined(Q_OS_MAC) && !defined(Q_OS_IOS)` have
been replaced with `#if defined(Q_OS_MACX)`.
Change-Id: I5055d9bd1845136beb8ed1c79a8f0f2c0897751a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Introducing a new method which allows us to know before hand if an URL
scheme will be supported by QNetworkAccessManager. It is especially useful in
combination with QFileDialog URL based methods to pass this list as the
allowed schemes the user can select in the dialog.
Change-Id: If625b045e87959bfd78fea2c9213b69caf506886
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In particular, set online state right upon construction of the
QNetworkAccessManager instance. Therefor, QNAM needs an instance of a
QNetworkConfigurationManager internally.
Before, this would only work properly if a network session was created.
Now, networkAccessible() returns the correct status.
Change-Id: I7ff9ccfd18ad376a131fc5977843b55bf185fba0
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
In case a network session is not required, we need access to the
configuration object rather than to the QString.
Change-Id: I05945525ce8247e343d0bebd7ec15e0e162ed826
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
... otherwise we would not read from the beginning when trying to
read again. The device is reset when we try to resend a request
(e.g. remote host closed etc.).
Change-Id: I21d3647dd0e00ae8bc2507f08166234f21f88861
Reviewed-by: Markus Goetz <markus@woboq.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Based on the Necessitas project by Bogdan Vatra.
Contributors to the Qt5 project:
BogDan Vatra <bogdan@kde.org>
Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
hjk <hjk121@nokiamail.com>
Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Paul Olav Tvete <paul.tvete@digia.com>
Robin Burchell <robin+qt@viroteck.net>
Samuel Rødal <samuel.rodal@digia.com>
Yoann Lopes <yoann.lopes@digia.com>
The full history of the Qt5 port can be found in refs/old-heads/android,
SHA-1 249ca9ca2c7d876b91b31df9434dde47f9065d0d
Change-Id: Iff1a7b2dbb707c986f2639e65e39ed8f22430120
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Add an encrypted signal to QNAM and QNetworkReply to allow applications
to perform additional checks on the certificate chain beyond those done
as part of the standard SSL validation. This allows things like
certificate change notification to be implemented for QNAM as they can
be for QSSLSocket currently.
Change-Id: I693e3e6fec8b7040379b7e7f1f819550e6b2617f
Reviewed-by: Peter Hartmann <phartmann@rim.com>
... because almost everybody gets it wrong almost every time.
Change-Id: I54938ef094323ba8de02186b585b11b9579f3ca4
Reviewed-by: Richard J. Moore <rich@kde.org>
i.e. make it obvious that they come from Qt.
This helps when debugging and trying to differ user created threads
from Qt threads.
Change-Id: Idd6804246d6676b17cf15de6b644a5be629aa023
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This improves performance since a network round trip can be avoided.
Change-Id: I1aaff7e48ef9638cb137de0f43942c3a4dd2884a
Initial-patch-by: Markus Goetz <markus@woboq.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
The macro was made empty in ba3dc5f3b5
and is no longer necessary or used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html
Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
... instead of a zero configuration. That is documented already for
QNetworkAccessManager::setConfiguration().
Task-number: QTBUG-28973
Change-Id: Idba5be990745069667a50c85286cf530580d4efe
Reviewed-by: Lorn Potter <lorn.potter@jollamobile.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Added a method to QNetworkReplyHttpImplPrivate to check whether the
HTTP operation used in the current request allows for caching. This
should only be the case if the operation is GET or HEAD. The response
to all other request are not really cacheable and should be disallowed
from caching.
Change-Id: I7c31bae42814d157a800d43565e5cb9adfb879f7
Task-number: QTBUG-28035
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Reviewed-by: Peter Hartmann <phartmann@rim.com>
