It could be that the channel has its reply already reset to 0, while
the protocol handler thinks the reply is still active, which might
lead to weird behavior including hard to reproduce crashes.
Task-number: QTBUG-37424
Change-Id: I89b65d34caaa546a343edc2ee205aa76425de88f
Reviewed-by: Richard J. Moore <rich@kde.org>
Correct the tense of send vs sent in comments and documentation.
Change-Id: I1c5ce9a7b1e49b8b0e8dcfde7d732e4c69acf73a
Reviewed-by: Kurt Pattyn <pattyn.kurt@gmail.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Task-number: QTBUG-37042
Change-Id: I7ddcbc315b4b720e7da7880fc00731c28beb4bb2
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Change-Id: I213ac1fb2733e675f3641441fe6c621bab06c1f0
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
We should not accept or process messages on closed streams, and unless
we are in a half-closed state (having initiated close ourselves), we
should respond to FIN with a FIN of our own.
This patch means we no longer trigger all the corner case teardown on
common sites that were fixed in earlier patches.
Change-Id: I0d2bab62700a0022a959e66c7053afbad07a9f7e
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
A QNetworkReply may be deleted before it is closed by the protocol.
Since QSpdyProtocolHandler tracks pointers to QNetworkReplies it must
keep track of their destruction as well to avoid links to deleted
objects.
This fixes the last issue with SPDY access of Google Mail in QtWebKit.
Change-Id: I2c56dc080fdcb249b6ed9189fef84cbbc1220cbd
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
We already remove QNetworkReply from most queues, but we also need
to remove it from the SPDY queue. Otherwise we might end up trying
to send an already deleted message.
Change-Id: Ib39bf8f26315b66179755a6f66dbd657576cbbe3
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
We should never upload on a SPDY stream in a closed or half-closed
state. To avoid it we need to stop listening for readyRead on the
upload device, and ignore WINDOW_UPDATE on completed streams.
This fixes SPDY access of facebook.com.
Change-Id: Icad45ffc109b2c14b921f1571e114b70a30f40a9
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Add handling of invalid stream-ids and buffer overflow in header
parsing.
Change-Id: I712af189d72612639d25890a8861a8f4fe084ce3
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
SPDY is currently assuming it will only receive RST_STREAM messages on
active steams. This is however not always a safe assumption.
Task-number: QTBUG-37100
Change-Id: Ied89a68a209891992ad72daa513066efc1d7c421
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
SPDY sends multiple header values for the same header key by null-byte
separating them.
This patch maps the multiple values the same way
qnetworkreplyhttpimpl.cpp
does. With this patch applied we can now log on to GMail using SPDY.
Change-Id: I03656ad1695d13b5c3ed252794dc6c89c67c7b97
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
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>
... from the private to the public class, because we need to access
these methods from other classes.
Change-Id: I2c5ea84e0f5d3641c1dc02342348f1022d886249
Reviewed-by: Richard J. Moore <rich@kde.org>
This bug causes that Cascades QML application cannot open more than
system ulimit defined number of different asset:///*.qml files.
The realFile is ordinary closed in the ~QNetworkReplyFileImpl(),
the QDeclarativeTypeLoader::::networkReplyFinished() calls
reply->deleteLater(). There are tricky situations when event-loop is
not entered and too many read already files are waiting for close.
This patch close() file when all the data is read. It can be done
this way since the QNetworkReplyFileImplnetworkreply is a sequential
device.
For more info, please, read comments on QTBUG-36032
Task-number: QTBUG-36032
Change-Id: I4002f21b4b0c7350af48b0dc6530d9606fd2794b
Reviewed-by: Richard J. Moore <rich@kde.org>
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
A few more HTTP status codes from the 4xx and 5xx series have been
added to QNetworkReply::NetworkError.
For content errors, the following codes have been added:
1. 409 - Resource Conflict
2. 410 - Resource Gone
For server related errors, the following codes have been added:
1. 500 - Internal Server Error
2. 501 - Operation Not Implemented
3. 503 - Service Unavailable
Few of the above codes are quite possible when communicating with REST
based services.
NOTE:
=====
* HTTP error status 400 is interpreted as
QNetworkReply::ProtocolInvalidOperationError.
* QNetworkReply::UnknownServerError is returned for all server related
errors (5xx) not listed above.
[ChangeLog][QtNetwork][QNetworkReply] Added more (specific) HTTP status
codes to NetworkError enum.
Task-number: QTBUG-30880
Change-Id: I9d2a133f6b3869f26710c6eb930dd8b08df31108
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
When the caches is deleted, the open files are deleted without closing action.
The file descriptor is remaining until the process is terminated.
Change-Id: If85519d173d05548ddf3273c85800441887199e2
Reviewed-by: jungo kim <jungo.kim@lge.com>
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Meego/Haramttan is no more and QtMobility only works for Qt 4.x anyway.
Change-Id: I3840358011f9d0e14de4d0ce9de15bba546964c5
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
For IPv6 addresses don't call toAce as it returns the empty string.
We should reflect the behavior of browsers here, which all accept
cookies from IPv6 addresses.
Original-patch-by: David Tapuska <dtapuska@blackberry.com>
Task-number: QTBUG-35022
Change-Id: Ic00369e923d044ec459822b2405865c13e4185b6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
If the domain is an IP address, we should not do any magic regarding
leading dots etc.
Task-number: QTBUG-35022
Change-Id: I7722de4e6027666dde27e9e37b6353e3da775d94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Richard J. Moore <rich@kde.org>
Add support for QNetworkAccessManager https REST on
iOS, without adding a dependency on OpenSSL.
The current limitations are:
- Overriding server certificate trust issues (for
example expired certificates) is not supported.
- Usage on non-gui threads is not supported.
NSurlConnection needs a CoreFoundation-based event
loop, which Qt currently only provides when using
QGuiApplication on the main thread.
Change-Id: Ic6f74591d40c3b2248ab81db12647e432377cd4f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
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>
