This is an in-depth article about how HTTP caching works in general and how it works with Qt.
When a browser loads a Web page, the different resources (HTML pages, images, CSS scripts etc.) are stored locally, so that next time the resource is retrieved, it can possibly be served from the local store instead of loading it from the network again. This has several benefits:
This article is mostly about finding out when a resource can be loaded from cache, and when it has to be loaded from the network.
The usual flow with HTTP caching goes like this: When the client (usually a browser) is requesting a resource via HTTP GET for the first time, it does usually not send any caching information with it. The server responds with a HTTP 200 OK message and the data, while it adds some headers to control caching on the client side, namely:
When the server responds to a client request, it sends information along whether the resource can be cached to disk and, if that is the case, how long the resource can be fetched from cache the next time the client loads it. In other words, it tells the client when the resource expires in the cache and has to be loaded from the network again. HTTP headers used by servers and proxies for sending expiration information are (list is not complete):
When the client has a resource in its cache locally, it can ask the server to send the resource only if it has changed. This involves always a roundtrip to the server, but might save data if the server tells the client that the resource has not changed since the client fetched it last time. In that case, the server sends an HTTP message with an empty body, instead of sending the data body as well. HTTP headers used for sending modification information are (list is not complete):
From the server:
From the client:
It is interesting to note that the headers involving absolute dates ("Expires", "Last-Modified", "If-Modified-Since") were already present in HTTP 1.0; the newer HTTP 1.1 standard resorts to means not involving dates, but time data relative to the client's clock ("max-age", "s-maxage") or versioning information ("ETag", "If-None-Match"). This is because in order of handling dates to work accurately, the server and client clocks need to be synchronized. ETags and relative time data provide more robust means that do not assume the clocks to be synchronized. That said, all of the headers presented above are still in widespread use.
By default, no disk cache is used when retrieving resources over HTTP with the QNetworkAccessManager class. In order to enable a cache, you need to either instantiate the QNetworkDiskCache class or write your own class deriving from QAbstractNetworkCache and then set it on your QNetworkAccessManager instance by calling setCache().
In that case, Qt will load resources from the cache if the resource is still fresh, and load from the network if not; if possible it adds modification information, as described above.
In order to fine-tune the behavior of how Qt loads resources from the network, you can set specific attributes in your QNetworkRequest by calling setAttribute() with QNetworkRequest::CacheLoadControlAttribute being one of:
If you want to fine-tune the caching behaviour even more, you could add headers (e.g. "Cache-Control: max-age" or "Cache-Control: max-stale") yourself via QNetworkRequest::setRawHeader().
As always, feel free to vote and comment on the tasks above.
Stay up to date with the latest marketing, sales and service tips and news.
Download the latest release here: www.qt.io/download.
Qt 5.12 was developed with a strong focus on quality and is a long-term-supported (LTS) release that will be supported for 3 years.
Näytä tämä julkaisu Instagramissa.
Want to build something for tomorrow, join #QtPeople today! We have loads of cool jobs you don’t want to miss! http://qt.io/careers #builtwithQt #software #developers #coding #framework #tool #tooling #C++ #QML #engineers #sales #tech #technology #UI #UX #CX #Qt #Qtdev #global #openpositions #careers #job
Henkilön Qt (@theqtcompany) jakama julkaisu