Shared Hosting for Everyone, imagined by developers, for developers.Discovering the Public Cloud
The HTTP cache temporarily stores web documents (e.g. HTML pages, CCS documents, images) to reduce the latency induced by the server when it needs to serve up a page and/or reduce its workload.
When a user attempts to access a page, the corresponding web server will generate a page and send it over the network. Then the cache intercepts the response to store it in its local memory before serving it up to the user.
When a request for the same page is sent by the same or another user, the cache will deliver it as it now has a copy of the requested resource. The web server will no longer be queried.
The standard’s specifications are set out in RFC 7234.
For the cache to query the upstream to determine if the requested resource has been modified, the application must provide the
A response CANNOT be cached if:
Content-Typeheader is not present,
Content-Typeis not one of the following values:
Cache-Controlheader takes one of the following values:
Set-Cookieheader is present,
Authorizationheader exists, but
Cache-Controltakes none of the following values:
This is done in Web > Sites > Edit the [site] - ⚙️ > Cache.
PURGE can be executed in three different ways at alwaysdata:
https://test.alwaysdata.net/foo/bar). This will remove the related cache entry and its variations (generated by the
X-Cache-Purge-Match: wildcardheader and adding a wildcard to your URL (e.g.
https://test.alwaysdata.net/*). This will remove all entries matching the URL template;
X-Cache-Purge-Match: startswithheader and adding a partial path to your URL (e.g.
https://test.alwaysdata.net/foo). This will remove all entries matching the URL template (and thus
While the HTTP cache is appropriate in most cases, you can also run Varnish on your alwaysdata account.