summaryrefslogtreecommitdiffstats
path: root/src/network/access/qhttpprotocolhandler.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QNAM: Prepare protocol handlers for local socketMårten Nordheim7 hours1-6/+6
| | | | | | | | | + a small stretch into adjacent functions, because some are used from the protocol handler(s). Task-number: QTBUG-102855 Change-Id: Ie394378fef2b1723e69286fd870fc34b7306734a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make QNAM handle all informational HTTP repliesMate Barany2024-02-061-1/+2
| | | | | | | | | | | | | | | | | | | 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>
* Http: simplify check for preconnect requestMårten Nordheim2023-11-061-2/+1
| | | | | Change-Id: I132533b9bc1f2b4d66f94599efb04def571cd2ff Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Replace qExchange calls with std::exchangeFabian Kosmale2022-09-281-3/+3
| | | | | | | | | | | | | | | | | | | | | qExchange is one of the few remaining functionalities that have not been moved out of qglobal. Given that std::exchange exists in the standard, we can simply move to it everywhere... ...if it weren't for the fact that std::exchange is only constexpr in C++20, and only has its noexceptness specified in (most likely) C++23. Still, we want to move to the existing std functionality where possible, to allow the removal of qglobal includes in lieu of something more fine-grained in the future. So leave any constexpr calls[1] alone for now (and observe that none of our current usages cares about the conditional noexceptness), but replace everything else. [1] QScopedValueRollback' ctor and QExplicitlySharedDataPointerV2::take Task-number: QTBUG-99313 Change-Id: I599cb9846cf319c7ffd3457130938347a75aad25 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use SPDX license identifiersLucie Gérard2022-05-161-39/+3
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QtNetwork: use _L1 for for creating Latin-1 string literalsSona Kurazyan2022-04-211-2/+3
| | | | | | Task-number: QTBUG-98434 Change-Id: Ic235b92377203f7a1429ae7fd784c4a1fa893e9f Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QHttp: Move the emission of requestSentMårten Nordheim2022-02-181-1/+2
| | | | | | | | | | | Moved to after the header is actually written, not just generated. For requests with data (put/post) we may have to wait for a callback before the data to write is available. Since we then delay writing the header as well it would be disingenuous to emit requestSent(). Pick-to: 6.3 Change-Id: I76c2d40ca48faaa1f6730ce8b3d5a8a4c3156f8f Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Move QNAM's http header parsing into separate classØystein Heskestad2021-09-091-2/+2
| | | | | | Fixes: QTBUG-80701 Change-Id: I43f5e102c15d121dba74e07e3cd4bb8aded1c763 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QNetworkReply: Add two new signalsMarkus Goetz2021-07-201-0/+2
| | | | | | | | | | | 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>
* QNetworkReply: Decompress when readingMårten Nordheim2021-06-121-2/+1
| | | | | | | | | | | Rather than when the data is received. Source compatibility is achieved through double-decompressing the data. This lets us know how many bytes are available just as before but without having the uncompressed data left in memory. Fixes: QTBUG-83269 Change-Id: I352bd09581614c582e4628243e2a0e895ba4946b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* HTTP: Don't call allDone twiceMårten Nordheim2021-04-291-0/+2
| | | | | | Change-Id: Ia3fb2e2c185f4e61234ce237416028b0c45357f8 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QNAM: try to send headers and body togetherGiuseppe D'Angelo2020-09-181-12/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For HTTP connections, QNAM defaults to opening its TCP socket in unbuffered mode. This means that Qt will send the data written into the socket right to the kernel, queueing only if the kernel says it doesn't want more data for the moment being. QNAM itself then uses separate write() calls to write the HTTP headers and the body of the request (like POST or PUT). These 2+ writes result in headers and body being sent over different TCP segments -- even if, in principle, a POST with a few bytes of data (e.g. a HTML form, or a REST or SOAP request) could fit in the same segment as the request. Multiple writes like this interact extremely poorly with other TCP features, e.g. delayed ACKs, Nagle's algorithm and the like. In a typical scenario, the kernel will send a segment containing just the headers, wait for the ACK (which may be delayed), and only then send the body (it wasn't sent before because Nagle was blocking it). The reply at this point is immediate (because the server can process the request and starts replying), but the delayed ACK is typically 40-50ms, and documented up to 500ms (!). If one uses QNAM to access a service, this introduces unacceptable latency. These multiple writes to the OS should be avoided. The first thing that comes into mind is to use buffered sockets. Now, there are good reasons to keep the socket unbuffered, so we don't want to change that. But the deal breaker is that even buffered sockets won't help in general: for instance, on Windows, a buffered write will immediately detect that the socket is ready for write and flush the buffer right away (not 100% sure of why this is necessary; basically, after populating the QTcpSocket write buffer, Qt enables a write socket notifier on the socket -- notifier that fires synchronously and immediately, without even returning to the event loop, and that causes the write buffer flush). Linux of course offers the perfect solution: corking the socket via TCP_CORK, which tells the kernel not to send the data right away but to buffer it up to a timeout (or when the option gets disabled again, whichever comes first). It's explicitly designed to support the case of sending headers followed by something like a sendfile(2). Setting this socket option moves the problem to the kernel and we could happily keep issuing multiple writes. Ça va sans dire, no other OS supports that option or any other similar option. We have therefore to deal with this in userspace: don't write in the socket multiple times, but try and coalesce the write of the headers with the writing of the data. This patch implements that, by storing the headers and sending them together with the very first chunk of data. If the data is small enough, this sends the entire request in one TCP segment. Interestingly enough, QNAM has a call setting TCP_NODELAY currently commented out because Qt doesn't combine "HTTP requests" (whatever that means). The call comes all the way back from pre-public history (before 2011) (!). This patch doesn't touch it. Fixes: QTBUG-41907 Change-Id: Id555d14e0702c9f75c3134b18277692eb3659afe Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Revert "QAbstractSocket: deprecate 'error' member-function"Alexander Akulich2020-02-261-1/+1
| | | | | | | | | | | | | | This reverts commit 94b3dd77f29a00ebbd1efdc66d75f57e1c75b152. The patch fixes ambiguity between a getter and a signal by changing the getter name, but we still have to rename the signal to follow the signals naming convention. Revert the commit to keep the getter as is and change the signal name instead. Change-Id: I0dd60cf1ae9d1bd95beeb8ad58661ca4b1fb63b9 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QAbstractSocket: deprecate 'error' member-functionTimur Pocheptsov2020-01-101-1/+1
| | | | | | | | | | | | The one that is a getter for the last error found. This is to disambiguate the expression '&QAbstractSocket::error'. Introduce a new member-function socketError as a replacement. [ChangeLog][Deprecation Notice] QAbstractSocket::error() (the getter) is deprecated; superseded by socketError(). Task-number: QTBUG-80369 Change-Id: Ia2e3d108657aaa7929ab0810babe2ede309740ba Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Tidy nullptr usageAllan Sandfeld Jensen2019-12-061-2/+2
| | | | | | | | | | | Move away from using 0 as pointer literal. Done using clang-tidy. This is not complete as run-clang-tidy can't handle all of qtbase in one go. Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Modernize use of 'http' featureUlf Hermann2017-11-061-4/+0
| | | | | | | | | | Exclude QHttp(Multi)Part from being built if http is disabled, and replace the exclusion macros. Use the qmake project files to exclude source files, and QT_REQUIRE_CONFIG(http) in headers. Change-Id: I432fa3c78aa97b5ed2eb1027ac1dc3bdb134f9ba Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* Support C++17 fallthrough attributeAllan Sandfeld Jensen2016-08-191-3/+4
| | | | | | | | | Replaces our mix of comments for annotating intended absence of break in switches with the C++17 attribute [[fallthrough]], or its earlier a clang extension counterpart. Change-Id: I4b2d0b9b5e4425819c7f1bf01608093c536b6d14 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Revert "Implement protocol upgrade for HTTP/2 enabled requests"Timur Pocheptsov2016-08-041-9/+0
| | | | | | | | | This reverts commit 12d71f4ea20415ff2274e1e90f9e4d5a8b935d7f. This change is breaking a build + incomplete as my test revealed. Will have to re-try later. Change-Id: I7ea089093a832aa5822caaaac56e62f5fda4df17 Reviewed-by: Liang Qi <liang.qi@qt.io>
* Implement protocol upgrade for HTTP/2 enabled requestsTimur Pocheptsov2016-08-031-0/+9
| | | | | | | | | | | | | | Without ALPN/NPN (== without OpenSSL) we can negotiate HTTP/2 using the protocol upgrade procedure as described by RFC7540. Since there is no TLS handshake, after our http channel was connected we first send an 'augmented' HTTP/1.1 request - its header contains additional 'HTTP2-Settings' and 'Upgrade' (to 'h2c') fields. If we receive reponse 101 (switch protocol) we re-create a protocol handler and switch to HTTP/2. Task-number: QTBUG-50955 Change-Id: I36e9985e06ba76edaf7fdb22bb43770f8d593c61 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QtNetwork: use printf-style qWarning/qDebug where possible (I)Marc Mutz2016-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The printf-style version of QDebug expands to a lot less code than the std::ostream-style version. Of course, you pay in type safety (but compilers warn about it these days), you cannot stream complex Qt types and streaming QStrings is awkward, but in many cases you actually improve on readability. But the main reason is that something that's not supposed to be executed under normal operation has no business bloating executable code size. This is not an attempt at converting all qWarnings() to printf-style, only the low-hanging fruit. In this first part, replace qWarning() << "" with qWarning("..."). Saves ~850b in text size on optimized GCC 5.3 AMD64 builds. Change-Id: Ib1a087795a03b2a6b432e2c499968df779aaea37 Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
* Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* QNAM: Fix reply deadlocks on server closing connectionMarkus Goetz2015-08-201-1/+6
| | | | | | | | | | | | | | | | The _q_readyRead can also be called from readMoreLater() because we implemented it so that bandwidth limited reading can be implemented. This can lead to a race condition if the socket is closing at the specific moment and then deadlock the channel: It will stay unusable with a zombie request. The fix in QHttpProtocolaHandler checks if there is actually bytes available to read from the socket and only then continue. The fix in the HTTP channel needs to be done to properly finish the reply in cases of a server replying with HTTP/1.0 or "Connection: close". The delayed incovation of _q_receiveReply will properly finish up the reply. Change-Id: I19ce2ae595f91d56386cc7406ccacc9935672b6b Reviewed-by: Richard J. Moore <rich@kde.org>
* Merge remote-tracking branch 'origin/5.4' into 5.5Oswald Buddenhagen2015-07-171-1/+0
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: doc/global/manifest-meta.qdocconf src/corelib/global/qnamespace.qdoc src/corelib/io/qstorageinfo_unix.cpp src/corelib/tools/qtools_p.h src/sql/drivers/psql/qsql_psql.cpp Change-Id: I23a15ac84e03ad61d865e3df872b013eb0752949
| * Network: Fix up previous corruption patchMarkus Goetz2015-07-081-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fix-up for cff39fba10ffc10ee4dcfdc66ff6528eb26462d3. That patch lead to some internal state issues that lead to the QTBUG-47048 or to QNetworkReply objects erroring with "Connection Closed" when the server closed the Keep-Alive connection. This patch changes the QNAM socket slot connections to be DirectConnection. We don't close the socket anymore in slots where it is anyway in a closed state afterwards. This prevents event/stack recursions. We also flush QSslSocket/QTcpSocket receive buffers when receiving a disconnect so that the developer always gets the full decrypted data from the buffers. [ChangeLog][QtNetwork] Fix HTTP issues with "Unknown Error" and "Connection Closed" [ChangeLog][QtNetwork][Sockets] Read OS/encrypted read buffers when connection closed by server. Change-Id: Ib4d6a2d0d988317e3a5356f36e8dbcee4590beed Task-number: QTBUG-47048 Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com> Reviewed-by: Richard J. Moore <rich@kde.org>
* | Merge remote-tracking branch 'origin/5.4' into merge5.5Allan Sandfeld Jensen2015-05-081-0/+7
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qglobal.h src/corelib/io/qnoncontiguousbytedevice_p.h src/gui/image/qjpeghandler.cpp src/network/access/qhttpthreaddelegate_p.h tests/auto/corelib/io/qlockfile/tst_qlockfile.cpp tests/auto/widgets/widgets/qmenubar/BLACKLIST Change-Id: I01de8c1c28efcedfd7953d05025f54802dc08ab3
| * QNAM: Fix upload corruptions when server closes connectionMarkus Goetz2015-04-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes several upload corruptions if the server closes the connection while/before we send data into it. They happen inside multiple places in the HTTP layer and are explained in the comments. Corruptions are: * The upload byte device has an in-flight signal with pending upload data, if it gets reset (because server closes the connection) then the re-send of the request was sometimes taking this stale in-flight pending upload data. * Because some signals were DirectConnection and some were QueuedConnection, there was a chance that a direct signal overtakes a queued signal. The state machine then sent data down the socket which was buffered there (and sent later) although it did not match the current state of the state machine when it was actually sent. * A socket was seen as being able to have requests sent even though it was not encrypted yet. This relates to the previous corruption where data is stored inside the socket's buffer and then sent later. The included auto test produces all fixed corruptions, I detected no regressions via the other tests. This code also adds a bit of sanity checking to protect from possible further problems. [ChangeLog][QtNetwork] Fix HTTP(s) upload corruption when server closes connection Change-Id: I54c883925ec897050941498f139c4b523030432e Reviewed-by: Peter Hartmann <peter-qt@hartmann.tk>
* | Update copyright headersJani Heikkinen2015-02-111-7/+7
|/ | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* Update license headers and add new license filesMatti Paaso2014-09-241-19/+11
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 - Removed LICENSE.GPL Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2 Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
* HTTP internals: introduce protocol handlersPeter Hartmann2014-02-131-0/+431
... 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>