| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Otherwise the connections will stay in a zombie state until the TCP
keep alive timer times out in a couple of hours.
Task-number: Maemo 201619
|
|
|
|
|
|
|
|
| |
This reverts commit cbf7a7782f465846455a5fd5df339ebde31a5521.
This commit caused autotest regressions in tst_qdeclarativeloader and
tst_qdeclarativetext; reverting it for now until this has been
resolved.
|
|\ |
|
| |
| |
| |
| | |
Reviewed-by: Markus Goetz
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To enable synchronous calls, an attribute in the QNetworkRequest has
to be set. If set, when QNetworkAccessManager::get() (and post(),
put()) returns, the reply is finished and all data has been read in
case of success.
This feature is semi-public for now (usable, but not documented).
To enable this, an attribute in the QNetworkRequest must be set. If
this attribute is set, we open a new connection to the server with
only one channel and call the channels' sockets' waitFor* methods.
Reviewed-by: Markus Goetz
|
|/
|
|
|
|
|
|
|
| |
QT-3494: During download, if a QAbstractSocket::RemoteHostClosedError occurs, the
error handling is deferred to _q_disconnected() slot. However, the error
message is not saved for the function, and thus the _q_disconnected only
emits a finished-signal.
Solution: Store an unhandled error into a private member. It is handled and
reset by the _q_disconnected (or more specifically, allDone-function).
|
|
|
|
|
| |
Task-number: QTBUG-15311
Reviewed-by: ogoffart
|
|
|
|
|
|
|
| |
Move the creation code to the top of QNAM::createRequest()
to avoid setting up a QNetworkSession when it is not needed.
Reviewed-by: ogoffart
|
| |
|
|
|
|
| |
Reviewed-by: Thiago Macieira
|
|
|
|
|
|
| |
Task-number: QTBUG-13431
Task-number: QTBUG-6276
Reviewed-by: ogoffart
|
|
|
|
|
|
|
| |
Reset authenticator and fix operator=(...) of QAuthenticator.
Task-number: QTBUG-6792
Reviewed-by: ogoffart
|
|
|
|
| |
Reviewed-by: Morten Engvoldsen
|
|
|
|
|
|
| |
Me no speak americano.
Reviewed-by: Peter Hartmann
|
|
|
|
|
|
|
|
| |
* winsock2.h conflicts with qplatformdefs.h
* ifndef QT_NO_OPENSSL was missing
Reviewed-by: Prasanth
Reviewed-by: Markus Goetz
|
|
|
|
|
|
|
|
| |
Removed the distinction between reply error and connection error.
The QNetworkAccessManager was treating them the same way anyway.
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
| |
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
|
| |
Pause the socket notifiers because the user could be displaying a
dialog which makes the event loop run and could make our socket
notifiers fire.
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
|
|
| |
Pause the socket notifiers because the user could be displaying a
dialog which makes the event loop run and could make our socket
notifiers fire.
Reviewed-by: Peter Hartmann
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
| |
Reviewed-by: Peter Hartmann
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
|
| |
Fixes a bug where a different QNetworkReply(Impl) handles an
authentication request.
Reviewed-by: Peter Hartmann
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed because user code might display a dialog which
spins an event loop and could make the sockets readyRead() fire.
This event loop recursion is not desired as it can lead to nasty
bugs when the state is messed up.
Reviewed-by: Peter Hartmann
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
| |
Copying the username and password messes up the state inside
the QAuthenticator. Do not do it.
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
| |
The credentials are now cached when the request gets sent.
Reviewed-by: Peter Hartmann
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
|
| |
The credentials shall only be loaded on demand, e.g. after the HTTP
code emits authenticationRequired()
Reviewed-by: Prasanth
Task-Number: QTBUG-13234
|
|
|
|
|
|
|
| |
This commit fixes getFromUnreachableIp()
Reviewed-by: Thiago Macieira
Task-Number: QTBUG-10679
|
|
|
|
|
|
|
| |
This was already fixed in 4.8, this is a hotfix for 4.7
Task-Number: QT-4096
Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
|
|
|
|
|
|
|
| |
Resources do not need network access and can be quicker
loaded with QFileNetworkReply.
Reviewed-by: Markus Goetz
|
|
|
|
|
|
|
|
|
|
| |
This one happened especially more often on amazon.de.
While one channel was taken by one request, but postponed because it
was still in disconnecting mode, another request would come, pick
the same channel, and overwrite the request/reply assignment of this
channel. The first request would be left unhandled eternally.
Reviewed-by: Markus Goetz
|
|
|
|
| |
Reviewed-by: Thomas Hartmann <thomas.hartmann@nokia.com>
|
|\
| |
| |
| | |
integration
|
| |
| |
| |
| |
| | |
The signal provides qint64, which cannot be connected to
QProgressBar::setValue(int).
|
|/ |
|
|
|
|
| |
Task-number: QTBUG-12285
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
doc/src/index.qdoc
src/dbus/qdbusconnection.cpp
src/gui/s60framework/qs60mainapplication.cpp
src/gui/s60framework/qs60mainappui.cpp
src/network/access/qnetworkrequest.cpp
src/network/bearer/qnetworkconfiguration.h
|
| | |
|
|/
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Peter Hartmann
|
|
|
|
| |
Reviewed-by: Markus Goetz
|
|
|
|
|
|
|
|
| |
Implementation will follow in 4.7.1 or 4.8, let's see.
Reviewed-by: David Boddie
Reviewed-by: Simon Hausmann
Reviewed-by: Peter Hartmann
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
| |
Merge-request: 715
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|