Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-19 02:10:26 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibHTTP/Cache/CacheIndex.cpp

388 lines
15 KiB
C++
Raw Permalink Normal View History

LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
/*
LibHTTP+LibWeb+RequestServer: Store request headers in the HTTP caches We need to store request headers in order to handle Vary mismatches. (Note we should also be using BLOB for header storage in sqlite, as they are not necessarily UTF-8.)
2025-12-24 11:08:14 -05:00
* Copyright (c) 2025-2026, Tim Flynn <trflynn89@ladybird.org>
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibHTTP: Place HTTP disk cache log points behind a debug flag These log points are quite verbose. Before we enable the disk cache by default, let's place them behind a debug flag.
2025-12-01 15:15:45 -05:00
#include <AK/Debug.h>
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
#include <AK/StringBuilder.h>
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
#include <LibFileSystem/FileSystem.h>
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
#include <LibHTTP/Cache/CacheIndex.h>
#include <LibHTTP/Cache/Utilities.h>
#include <LibHTTP/Cache/Version.h>
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
namespace HTTP {
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
RequestServer: Create a cache metadata table This currently just holds a cache version. If we make a breaking change to the cache format, we can increment the version here to wipe the cache database. This is certainly a blunt hammer approach; we will want to handle such changes more gracefully when we can.
2025-10-29 12:39:08 -04:00
static constexpr u32 CACHE_METADATA_KEY = 12389u;
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
static ByteString serialize_headers(HeaderList const& headers)
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
{
StringBuilder builder;
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
for (auto const& header : headers) {
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
builder.append(header.name);
builder.append(':');
builder.append(header.value);
builder.append('\n');
}
return builder.to_byte_string();
}
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
static NonnullRefPtr<HeaderList> deserialize_headers(StringView serialized_headers)
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
{
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
auto headers = HeaderList::create();
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
serialized_headers.for_each_split_view('\n', SplitBehavior::Nothing, [&](StringView serialized_header) {
auto index = serialized_header.find(':');
if (!index.has_value())
return;
LibHTTP: Correctly normalize header whitespace in cache utilities We also shouldn't trim whitespace at all when reading headers from the cache index. We store them as-is and should therefore read them as-is.
2026-02-26 15:04:14 -05:00
auto name = serialized_header.substring_view(0, *index);
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
if (is_header_exempted_from_storage(name))
return;
LibHTTP: Correctly normalize header whitespace in cache utilities We also shouldn't trim whitespace at all when reading headers from the cache index. We store them as-is and should therefore read them as-is.
2026-02-26 15:04:14 -05:00
auto value = serialized_header.substring_view(*index + 1);
LibHTTP+LibWeb+RequestServer: Move Fetch's HTTP header infra to LibHTTP The end goal here is for LibHTTP to be the home of our RFC 9111 (HTTP caching) implementation. We currently have one implementation in LibWeb for our in-memory cache and another in RequestServer for our disk cache. The implementations both largely revolve around interacting with HTTP headers. But in LibWeb, we are using Fetch's header infra, and in RS we are using are home-grown header infra from LibHTTP. So to give these a common denominator, this patch replaces the LibHTTP implementation with Fetch's infra. Our existing LibHTTP implementation was not particularly compliant with any spec, so this at least gives us a standards-based common implementation. This migration also required moving a handful of other Fetch AOs over to LibHTTP. (It turns out these AOs were all from the Fetch/Infra/HTTP folder, so perhaps it makes sense for LibHTTP to be the implementation of that entire set of facilities.)
2025-11-26 14:13:23 -05:00
headers->append({ name, value });
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
});
return headers;
}
LibHTTP: Use a memory-backed database for the disk cache in test modes This just lets us create fewer cache directories during WPT. We do still create cache entries on disk, so for WPT, we introduce an extra cache key to prevent conflicts. There is an existing FIXME about this.
2026-02-15 09:35:44 -05:00
ErrorOr<CacheIndex> CacheIndex::create(Database::Database& database, LexicalPath const& cache_directory)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
{
RequestServer: Create a cache metadata table This currently just holds a cache version. If we make a breaking change to the cache format, we can increment the version here to wipe the cache database. This is certainly a blunt hammer approach; we will want to handle such changes more gracefully when we can.
2025-10-29 12:39:08 -04:00
auto create_cache_metadata_table = TRY(database.prepare_statement(R"#(
CREATE TABLE IF NOT EXISTS CacheMetadata (
metadata_key INTEGER,
version INTEGER,
PRIMARY KEY(metadata_key)
);
)#"sv));
database.execute_statement(create_cache_metadata_table, {});
auto read_cache_version = TRY(database.prepare_statement("SELECT version FROM CacheMetadata WHERE metadata_key = ?;"sv));
auto cache_version = 0u;
database.execute_statement(
read_cache_version,
[&](auto statement_id) { cache_version = database.result_column<u32>(statement_id, 0); },
CACHE_METADATA_KEY);
if (cache_version != CACHE_VERSION) {
RequestServer: Do not log disk cache version mismatches on first-run Particularly on test runs, this is just noise.
2025-11-20 15:11:01 -05:00
if (cache_version != 0)
LibHTTP: Prefix disk cache debug messages with "[disk]" text A future commit will format memory cache debug messages similarly to the disk cache messages. To make it easy to read them both at a glance when both debug flags are turned on, let's add a prefix to these messages.
2026-01-09 11:36:47 -05:00
dbgln_if(HTTP_DISK_CACHE_DEBUG, "\033[36m[disk]\033[0m \033[31;1mDisk cache version mismatch:\033[0m stored version = {}, new version = {}", cache_version, CACHE_VERSION);
RequestServer: Create a cache metadata table This currently just holds a cache version. If we make a breaking change to the cache format, we can increment the version here to wipe the cache database. This is certainly a blunt hammer approach; we will want to handle such changes more gracefully when we can.
2025-10-29 12:39:08 -04:00
// FIXME: We should more elegantly handle minor changes, i.e. use ALTER TABLE to add fields to CacheIndex.
auto delete_cache_index_table = TRY(database.prepare_statement("DROP TABLE IF EXISTS CacheIndex;"sv));
database.execute_statement(delete_cache_index_table, {});
auto set_cache_version = TRY(database.prepare_statement("INSERT OR REPLACE INTO CacheMetadata VALUES (?, ?);"sv));
database.execute_statement(set_cache_version, {}, CACHE_METADATA_KEY, CACHE_VERSION);
}
auto create_cache_index_table = TRY(database.prepare_statement(R"#(
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
CREATE TABLE IF NOT EXISTS CacheIndex (
cache_key INTEGER,
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
vary_key INTEGER,
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
url TEXT,
LibHTTP+LibWeb+RequestServer: Store request headers in the HTTP caches We need to store request headers in order to handle Vary mismatches. (Note we should also be using BLOB for header storage in sqlite, as they are not necessarily UTF-8.)
2025-12-24 11:08:14 -05:00
request_headers BLOB,
response_headers BLOB,
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
data_size INTEGER,
request_time INTEGER,
response_time INTEGER,
last_access_time INTEGER,
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
PRIMARY KEY(cache_key, vary_key)
RequestServer: Create a cache metadata table This currently just holds a cache version. If we make a breaking change to the cache format, we can increment the version here to wipe the cache database. This is certainly a blunt hammer approach; we will want to handle such changes more gracefully when we can.
2025-10-29 12:39:08 -04:00
);
)#"sv));
database.execute_statement(create_cache_index_table, {});
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
Statements statements {};
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
statements.insert_entry = TRY(database.prepare_statement("INSERT OR REPLACE INTO CacheIndex VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?);"sv));
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
statements.remove_entry = TRY(database.prepare_statement(R"#(
DELETE FROM CacheIndex
WHERE cache_key = ? AND vary_key = ?
RETURNING data_size + OCTET_LENGTH(request_headers) + OCTET_LENGTH(response_headers);
)#"sv));
statements.remove_entries_accessed_since = TRY(database.prepare_statement(R"#(
DELETE FROM CacheIndex
WHERE last_access_time >= ?
RETURNING cache_key, vary_key, data_size + OCTET_LENGTH(request_headers) + OCTET_LENGTH(response_headers);
)#"sv));
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
statements.select_entries = TRY(database.prepare_statement("SELECT * FROM CacheIndex WHERE cache_key = ?;"sv));
statements.update_response_headers = TRY(database.prepare_statement("UPDATE CacheIndex SET response_headers = ? WHERE cache_key = ? AND vary_key = ?;"sv));
statements.update_last_access_time = TRY(database.prepare_statement("UPDATE CacheIndex SET last_access_time = ? WHERE cache_key = ? AND vary_key = ?;"sv));
LibHTTP: Include request header length in the estimated disk cache size Request headers were added in 36a826815dbf1fd7f2b9ec7481a450994ff36066, but this estimation was not updated.
2026-02-04 17:29:04 -05:00
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
statements.remove_entries_exceeding_cache_limit = TRY(database.prepare_statement(R"#(
WITH RankedCacheIndex AS (
SELECT
cache_key,
vary_key,
SUM(data_size + OCTET_LENGTH(request_headers) + OCTET_LENGTH(response_headers))
OVER (ORDER BY last_access_time DESC)
AS cumulative_estimated_size
FROM CacheIndex
)
DELETE FROM CacheIndex
WHERE (cache_key, vary_key) IN (
SELECT cache_key, vary_key
FROM RankedCacheIndex
WHERE cumulative_estimated_size > ?
)
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
RETURNING cache_key, vary_key, data_size + OCTET_LENGTH(request_headers) + OCTET_LENGTH(response_headers);
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
)#"sv));
LibHTTP: Include request header length in the estimated disk cache size Request headers were added in 36a826815dbf1fd7f2b9ec7481a450994ff36066, but this estimation was not updated.
2026-02-04 17:29:04 -05:00
statements.estimate_cache_size_accessed_since = TRY(database.prepare_statement(R"#(
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
SELECT COALESCE(SUM(data_size + OCTET_LENGTH(request_headers) + OCTET_LENGTH(response_headers)), 0)
LibHTTP: Include request header length in the estimated disk cache size Request headers were added in 36a826815dbf1fd7f2b9ec7481a450994ff36066, but this estimation was not updated.
2026-02-04 17:29:04 -05:00
FROM CacheIndex
WHERE last_access_time >= ?;
)#"sv));
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
statements.select_total_estimated_size = TRY(database.prepare_statement(R"#(
SELECT COALESCE(SUM(data_size + OCTET_LENGTH(request_headers) + OCTET_LENGTH(response_headers)), 0)
FROM CacheIndex;
)#"sv));
LibHTTP: Use a memory-backed database for the disk cache in test modes This just lets us create fewer cache directories during WPT. We do still create cache entries on disk, so for WPT, we introduce an extra cache key to prevent conflicts. There is an existing FIXME about this.
2026-02-15 09:35:44 -05:00
auto disk_space = TRY(FileSystem::compute_disk_space(cache_directory));
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
auto maximum_disk_cache_size = compute_maximum_disk_cache_size(disk_space.free_bytes);
Limits limits {
.free_disk_space = disk_space.free_bytes,
.maximum_disk_cache_size = maximum_disk_cache_size,
LibHTTP: Impose a limit on singular disk cache entry sizes Let's not attempt to cache entries that are excessively large. We limit the cache data size to be 1/8 of the total disk cache limit, with a cap of 256 MiB.
2026-02-04 19:03:41 -05:00
.maximum_disk_cache_entry_size = compute_maximum_disk_cache_entry_size(maximum_disk_cache_size),
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
};
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
u64 total_estimated_size { 0 };
database.execute_statement(
statements.select_total_estimated_size,
[&](auto statement_id) { total_estimated_size = database.result_column<u64>(statement_id, 0); });
return CacheIndex { database, statements, limits, total_estimated_size };
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
}
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
CacheIndex::CacheIndex(Database::Database& database, Statements statements, Limits limits, u64 total_estimated_size)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
: m_database(database)
, m_statements(statements)
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
, m_limits(limits)
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
, m_total_estimated_size(total_estimated_size)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
{
}
LibHTTP: Impose a limit on singular disk cache entry sizes Let's not attempt to cache entries that are excessively large. We limit the cache data size to be 1/8 of the total disk cache limit, with a cap of 256 MiB.
2026-02-04 19:03:41 -05:00
ErrorOr<void> CacheIndex::create_entry(u64 cache_key, u64 vary_key, String url, NonnullRefPtr<HeaderList> request_headers, NonnullRefPtr<HeaderList> response_headers, u64 data_size, UnixDateTime request_time, UnixDateTime response_time)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
{
auto now = UnixDateTime::now();
LibHTTP+LibWeb+RequestServer: Store request headers in the HTTP caches We need to store request headers in order to handle Vary mismatches. (Note we should also be using BLOB for header storage in sqlite, as they are not necessarily UTF-8.)
2025-12-24 11:08:14 -05:00
auto remove_exempted_headers = [](HeaderList& headers) {
LibHTTP: Avoid UAF while deleting exempt cache headers HeaderList::delete involves a Vector::remove_all_matching internally. So if an exempt header appeared again later in the header list, we would be accessing the name string of the previously deleted header.
2026-01-22 12:39:23 -05:00
headers.delete_all_matching([&](auto const& header) {
return is_header_exempted_from_storage(header.name);
});
LibHTTP+LibWeb+RequestServer: Store request headers in the HTTP caches We need to store request headers in order to handle Vary mismatches. (Note we should also be using BLOB for header storage in sqlite, as they are not necessarily UTF-8.)
2025-12-24 11:08:14 -05:00
};
remove_exempted_headers(request_headers);
remove_exempted_headers(response_headers);
RequestServer: Remove headers exempted from storage from in-memory cache We previously excluded headers exempted from storage when we serialized the headers into the database. However, we stored the original headers in-memory. So when a subsequent request hit CacheIndex::find_entry, we would return an entry with response headers that should have been excluded.
2025-11-16 11:49:06 -05:00
LibHTTP: Impose a limit on singular disk cache entry sizes Let's not attempt to cache entries that are excessively large. We limit the cache data size to be 1/8 of the total disk cache limit, with a cap of 256 MiB.
2026-02-04 19:03:41 -05:00
auto serialized_request_headers = serialize_headers(request_headers);
auto serialized_response_headers = serialize_headers(response_headers);
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
Entry entry {
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
.vary_key = vary_key,
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
.url = move(url),
LibHTTP+LibWeb+RequestServer: Store request headers in the HTTP caches We need to store request headers in order to handle Vary mismatches. (Note we should also be using BLOB for header storage in sqlite, as they are not necessarily UTF-8.)
2025-12-24 11:08:14 -05:00
.request_headers = move(request_headers),
RequestServer: Store HTTP response headers in the cache index We currently store response headers in the cache entry file, before the response body. When we implement cache revalidation, we will need to update the stored response headers with whatever headers are received in a 304 response. It's not unlikely that those headers will have a size that differs from the stored headers. We would then have to rewrite the entire response body after the new headers. Instead of dealing with those inefficiencies, let's instead store the response headers in the cache index. This will allow us to update the headers with a simple SQL query.
2025-10-29 15:36:33 -04:00
.response_headers = move(response_headers),
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
.data_size = data_size,
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
.serialized_request_headers_size = static_cast<u64>(serialized_request_headers.length()),
.serialized_response_headers_size = static_cast<u64>(serialized_response_headers.length()),
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
.request_time = request_time,
.response_time = response_time,
.last_access_time = now,
};
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
auto entry_size = entry.estimated_size();
if (entry_size > m_limits.maximum_disk_cache_entry_size)
return Error::from_string_literal("Cache entry size exceeds allowed maximum");
m_database->execute_statement(
m_statements.remove_entry,
[&](auto statement_id) {
auto removed_size = m_database->result_column<u64>(statement_id, 0);
m_total_estimated_size -= removed_size;
},
cache_key,
vary_key);
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
LibHTTP: Replace loaded cache entries in CacheIndex create_entry() issues INSERT OR REPLACE in SQL, so the on-disk row is correctly overwritten when a (cache_key, vary_key) pair is re-inserted. But the in-memory m_entries vector was only appended to, leaving the stale Entry alongside the new one. Subsequent find_entry() calls could then return the old metadata even though the DB had moved on.
2026-04-17 16:53:04 +02:00
auto& entries = m_entries.ensure(cache_key);
auto existing_entry_index = entries.find_first_index_if([&](auto const& existing_entry) {
return existing_entry.vary_key == vary_key;
});
LibHTTP: Impose a limit on singular disk cache entry sizes Let's not attempt to cache entries that are excessively large. We limit the cache data size to be 1/8 of the total disk cache limit, with a cap of 256 MiB.
2026-02-04 19:03:41 -05:00
m_database->execute_statement(m_statements.insert_entry, {}, cache_key, vary_key, entry.url, serialized_request_headers, serialized_response_headers, entry.data_size, entry.request_time, entry.response_time, entry.last_access_time);
LibHTTP: Replace loaded cache entries in CacheIndex create_entry() issues INSERT OR REPLACE in SQL, so the on-disk row is correctly overwritten when a (cache_key, vary_key) pair is re-inserted. But the in-memory m_entries vector was only appended to, leaving the stale Entry alongside the new one. Subsequent find_entry() calls could then return the old metadata even though the DB had moved on.
2026-04-17 16:53:04 +02:00
if (existing_entry_index.has_value())
entries[*existing_entry_index] = move(entry);
else
entries.append(move(entry));
LibHTTP: Impose a limit on singular disk cache entry sizes Let's not attempt to cache entries that are excessively large. We limit the cache data size to be 1/8 of the total disk cache limit, with a cap of 256 MiB.
2026-02-04 19:03:41 -05:00
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
m_total_estimated_size += entry_size;
LibHTTP: Impose a limit on singular disk cache entry sizes Let's not attempt to cache entries that are excessively large. We limit the cache data size to be 1/8 of the total disk cache limit, with a cap of 256 MiB.
2026-02-04 19:03:41 -05:00
return {};
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
}
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
void CacheIndex::remove_entry(u64 cache_key, u64 vary_key)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
{
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
m_database->execute_statement(
m_statements.remove_entry,
[&](auto statement_id) {
auto removed_size = m_database->result_column<u64>(statement_id, 0);
m_total_estimated_size -= removed_size;
},
cache_key,
vary_key);
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
delete_entry(cache_key, vary_key);
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
}
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
void CacheIndex::remove_entries_exceeding_cache_limit(Function<void(u64 cache_key, u64 vary_key)> on_entry_removed)
LibWebView+RequestServer: Support clearing the HTTP disk cache This is a bit of a blunt hammer, but this hooks an action to clear the HTTP disk cache into the existing Clear Cache action. Upon invocation, it stops all existing cache entries from making further progress, and then deletes the entire cache index and all cache files. In the future, we will of course want more fine-grained control over cache deletion, e.g. via an about:history page.
2025-10-09 14:24:47 -04:00
{
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
if (m_total_estimated_size <= m_limits.maximum_disk_cache_size)
return;
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
m_database->execute_statement(
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
m_statements.remove_entries_exceeding_cache_limit,
RequestServer: Add a time parameter to the clear cache endpoint This allows removing cache entries last accessed since a provided timestamp.
2025-11-02 16:44:30 -05:00
[&](auto statement_id) {
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
auto cache_key = m_database->result_column<u64>(statement_id, 0);
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
auto vary_key = m_database->result_column<u64>(statement_id, 1);
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
auto removed_size = m_database->result_column<u64>(statement_id, 2);
m_total_estimated_size -= removed_size;
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
delete_entry(cache_key, vary_key);
RequestServer: Add a time parameter to the clear cache endpoint This allows removing cache entries last accessed since a provided timestamp.
2025-11-02 16:44:30 -05:00
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
if (on_entry_removed)
on_entry_removed(cache_key, vary_key);
},
m_limits.maximum_disk_cache_size);
}
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
void CacheIndex::remove_entries_accessed_since(UnixDateTime since, Function<void(u64 cache_key, u64 vary_key)> on_entry_removed)
{
m_database->execute_statement(
m_statements.remove_entries_accessed_since,
[&](auto statement_id) {
auto cache_key = m_database->result_column<u64>(statement_id, 0);
auto vary_key = m_database->result_column<u64>(statement_id, 1);
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
auto removed_size = m_database->result_column<u64>(statement_id, 2);
m_total_estimated_size -= removed_size;
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
delete_entry(cache_key, vary_key);
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
if (on_entry_removed)
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
on_entry_removed(cache_key, vary_key);
RequestServer: Add a time parameter to the clear cache endpoint This allows removing cache entries last accessed since a provided timestamp.
2025-11-02 16:44:30 -05:00
},
since);
LibWebView+RequestServer: Support clearing the HTTP disk cache This is a bit of a blunt hammer, but this hooks an action to clear the HTTP disk cache into the existing Clear Cache action. Upon invocation, it stops all existing cache entries from making further progress, and then deletes the entire cache index and all cache files. In the future, we will of course want more fine-grained control over cache deletion, e.g. via an about:history page.
2025-10-09 14:24:47 -04:00
}
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
void CacheIndex::update_response_headers(u64 cache_key, u64 vary_key, NonnullRefPtr<HeaderList> response_headers)
RequestServer: Implement stale cache revalidation When a request becomes stale, we will now issue a revalidation request (if the response indicates it may be revalidated). We do this by issuing a normal fetch request, with If-None-Match and/or If-Modified-Since request headers. If the server replies with an HTTP 304 status, we update the stored response headers to match the 304's headers, and serve the response to the client from the cache. If the server replies with any other code, we remove the cache entry. We will open a new cache entry to cache the new response, if possible.
2025-10-28 17:09:35 -04:00
{
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
auto entry = get_entry(cache_key, vary_key);
RequestServer: Implement stale cache revalidation When a request becomes stale, we will now issue a revalidation request (if the response indicates it may be revalidated). We do this by issuing a normal fetch request, with If-None-Match and/or If-Modified-Since request headers. If the server replies with an HTTP 304 status, we update the stored response headers to match the 304's headers, and serve the response to the client from the cache. If the server replies with any other code, we remove the cache entry. We will open a new cache entry to cache the new response, if possible.
2025-10-28 17:09:35 -04:00
if (!entry.has_value())
return;
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
auto serialized_response_headers = serialize_headers(response_headers);
auto serialized_response_headers_size = static_cast<u64>(serialized_response_headers.length());
m_database->execute_statement(m_statements.update_response_headers, {}, serialized_response_headers, cache_key, vary_key);
m_total_estimated_size -= entry->serialized_response_headers_size;
m_total_estimated_size += serialized_response_headers_size;
RequestServer: Implement stale cache revalidation When a request becomes stale, we will now issue a revalidation request (if the response indicates it may be revalidated). We do this by issuing a normal fetch request, with If-None-Match and/or If-Modified-Since request headers. If the server replies with an HTTP 304 status, we update the stored response headers to match the 304's headers, and serve the response to the client from the cache. If the server replies with any other code, we remove the cache entry. We will open a new cache entry to cache the new response, if possible.
2025-10-28 17:09:35 -04:00
entry->response_headers = move(response_headers);
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
entry->serialized_response_headers_size = serialized_response_headers_size;
RequestServer: Implement stale cache revalidation When a request becomes stale, we will now issue a revalidation request (if the response indicates it may be revalidated). We do this by issuing a normal fetch request, with If-None-Match and/or If-Modified-Since request headers. If the server replies with an HTTP 304 status, we update the stored response headers to match the 304's headers, and serve the response to the client from the cache. If the server replies with any other code, we remove the cache entry. We will open a new cache entry to cache the new response, if possible.
2025-10-28 17:09:35 -04:00
}
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
void CacheIndex::update_last_access_time(u64 cache_key, u64 vary_key)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
{
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
auto entry = get_entry(cache_key, vary_key);
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
if (!entry.has_value())
return;
auto now = UnixDateTime::now();
LibHTTP: Ensure we use the Vary key when updating last access time Apparently, sqlite will fill this placeholder value in with NULL if we do not pass a value. The query being executed here is: UPDATE CacheIndex SET last_access_time = ? WHERE cache_key = ? AND vary_key = ?;
2026-02-06 08:24:42 -05:00
m_database->execute_statement(m_statements.update_last_access_time, {}, now, cache_key, vary_key);
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
entry->last_access_time = now;
}
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
Optional<CacheIndex::Entry const&> CacheIndex::find_entry(u64 cache_key, HeaderList const& request_headers)
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
{
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
auto& entries = m_entries.ensure(cache_key, [&]() {
Vector<Entry> entries;
m_database->execute_statement(
m_statements.select_entries,
[&](auto statement_id) {
int column = 1; // Skip the cache_key column.
auto vary_key = m_database->result_column<u64>(statement_id, column++);
auto url = m_database->result_column<String>(statement_id, column++);
auto request_headers = m_database->result_column<ByteString>(statement_id, column++);
auto response_headers = m_database->result_column<ByteString>(statement_id, column++);
auto data_size = m_database->result_column<u64>(statement_id, column++);
auto request_time = m_database->result_column<UnixDateTime>(statement_id, column++);
auto response_time = m_database->result_column<UnixDateTime>(statement_id, column++);
auto last_access_time = m_database->result_column<UnixDateTime>(statement_id, column++);
LibHTTP: Short-circuit CacheIndex eviction when under its size limit remove_entries_exceeding_cache_limit() is called after every network response, but the cache is usually still under budget and nothing needs to evict. Every one of those calls currently still runs the window-function eviction SQL over the whole CacheIndex table just to conclude there is nothing to do. Short-circuit the call when the cache is already within its configured size limit. To make that check cheap, maintain m_total_estimated_size as a running total of the cache's estimated byte size, so the no-op case becomes a single u64 compare and the DB is only touched when there is real work. Bookkeeping: - Seed the total in CacheIndex::create() via a new select_total_estimated_size statement (COALESCE(..., 0) so an empty index returns 0 rather than NULL). - Each Entry caches serialized_request_headers_size and serialized_response_headers_size so we don't re-serialize to recompute its footprint; Entry::estimated_size() centralizes the arithmetic. - create_entry() adds the new entry's size. Any row it displaces is removed via DELETE ... RETURNING so the total stays accurate even for entries that were never loaded into m_entries. - remove_entry() and the bulk DELETE statements were extended with the same RETURNING clause for the same reason. - update_response_headers() shifts the total by the signed delta between old and new serialized header size. Also COALESCEs estimate_cache_size_accessed_since over an empty table to 0 so callers don't have to special-case NULL.
2026-04-17 16:54:21 +02:00
entries.empend(vary_key, move(url), deserialize_headers(request_headers), deserialize_headers(response_headers), data_size, request_headers.length(), response_headers.length(), request_time, response_time, last_access_time);
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
},
cache_key);
return entries;
});
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
return find_value(entries, [&](auto const& entry) {
return create_vary_key(request_headers, entry.response_headers) == entry.vary_key;
});
}
Optional<CacheIndex::Entry&> CacheIndex::get_entry(u64 cache_key, u64 vary_key)
{
auto entries = m_entries.get(cache_key);
if (!entries.has_value())
return {};
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
LibHTTP+LibWeb: Support the HTTP Vary response header We now partition the HTTP disk cache based on the Vary response header. If a cached response contains a Vary header, we look for each of the header names in the outgoing HTTP request. The outgoing request must match every header value in the original request for the cache entry to be used; otherwise, a new request will be issued, and a separate cache entry will be created. Note that we must now defer creating the disk cache file itself until we have received the response headers. The Vary key is computed from these headers, and affects the partitioned disk cache file name. There are further optimizations we can make here. If we have a Vary mismatch, we could find the best candidate cached response and issue a conditional HTTP request. The content server may then respond with an HTTP 304 if the mismatched request headers are actually okay. But for now, if we have a Vary mismatch, we issue an unconditional request as a purely correctness-oriented patch.
2025-12-28 10:23:56 -05:00
return find_value(*entries, [&](auto const& entry) { return entry.vary_key == vary_key; });
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
}
LibHTTP: Impose a limit on the total disk cache size Rather than letting our disk cache grow unbounded, let's impose a limit on the estimated total disk cache size. The limits chosen are vaguely inspired by Chromium. We impose a total disk cache limit of 5 GiB. Chromium imposes an overall limit of 1.25 GiB; I've chosen more here because we currently cache uncompressed data from cURL. The limit is further restricted by the amount of available disk space, which we just check once at startup (as does Chromium). We will choose a percentage of the free space available on systems with limited space. Our eviction errs on the side of simplicity. We will remove the least recently accessed entries until the total estimated cache size does not exceed our limit. This could potentially be improved in the future. For example, if the next entry to consider is 40 MiB, and we only need to free 1 MiB of space, we could try evicting slightly more recently used entries. This would prevent evicting more than we need to.
2026-02-04 17:53:00 -05:00
void CacheIndex::delete_entry(u64 cache_key, u64 vary_key)
{
auto entries = m_entries.get(cache_key);
if (!entries.has_value())
return;
entries->remove_first_matching([&](auto const& entry) { return entry.vary_key == vary_key; });
if (entries->is_empty())
m_entries.remove(cache_key);
}
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
Requests::CacheSizes CacheIndex::estimate_cache_size_accessed_since(UnixDateTime since)
LibRequests+RequestServer: Add a method to estimate disk cache size This allows estimating the cache size stored on disk since a provided time stamp, and in total.
2025-11-02 13:10:27 -05:00
{
Requests::CacheSizes sizes;
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
m_database->execute_statement(
LibRequests+RequestServer: Add a method to estimate disk cache size This allows estimating the cache size stored on disk since a provided time stamp, and in total.
2025-11-02 13:10:27 -05:00
m_statements.estimate_cache_size_accessed_since,
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
[&](auto statement_id) { sizes.since_requested_time = m_database->result_column<u64>(statement_id, 0); },
LibRequests+RequestServer: Add a method to estimate disk cache size This allows estimating the cache size stored on disk since a provided time stamp, and in total.
2025-11-02 13:10:27 -05:00
since);
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
m_database->execute_statement(
LibRequests+RequestServer: Add a method to estimate disk cache size This allows estimating the cache size stored on disk since a provided time stamp, and in total.
2025-11-02 13:10:27 -05:00
m_statements.estimate_cache_size_accessed_since,
LibHTTP+RequestServer: Move the HTTP cache implementation to LibHTTP We currently have two ongoing implementations of RFC 9111, HTTP caching. In order to consolidate these, this patch moves the implementation from RequestServer to LibHTTP for re-use within LibWeb.
2025-11-28 10:04:59 -05:00
[&](auto statement_id) { sizes.total = m_database->result_column<u64>(statement_id, 0); },
LibRequests+RequestServer: Add a method to estimate disk cache size This allows estimating the cache size stored on disk since a provided time stamp, and in total.
2025-11-02 13:10:27 -05:00
UnixDateTime::earliest());
return sizes;
}
LibHTTP+LibWebView+RequestServer: Allow users to set disk cache limits This adds a settings box to about:settings to allow users to limit the disk cache size. This will override the default 5 GiB limit. We do not automatically delete cache data if the new limit is suddenly less than the used disk space; this will happen on the next request. This allows multiple changes to the settings in a row without thrashing the cache. In the future, we can add more toggles, such as disabling the disk cache altogether.
2026-02-05 12:25:14 -05:00
void CacheIndex::set_maximum_disk_cache_size(u64 maximum_disk_cache_size)
{
if (maximum_disk_cache_size == m_limits.maximum_disk_cache_size)
return;
m_limits.maximum_disk_cache_size = compute_maximum_disk_cache_size(m_limits.free_disk_space, maximum_disk_cache_size);
m_limits.maximum_disk_cache_entry_size = compute_maximum_disk_cache_entry_size(m_limits.maximum_disk_cache_size);
}
LibRequests+RequestServer: Begin implementing an HTTP disk cache This adds a disk cache for HTTP responses received from the network. For now, we take a rather conservative approach to caching. We don't cache a response until we're 100% sure it is cacheable (there are heuristics we can implement in the future based on the absence of specific headers). The cache is broken into 2 categories of files: 1. An index file. This is a SQL database containing metadata about each cache entry (URL, timestamps, etc.). 2. Cache files. Each cached response is in its own file. The file is an amalgamation of all info needed to reconstruct an HTTP response. This includes the status code, headers, body, etc. A cache entry is created once we receive the headers for a response. The index, however, is not updated at this point. We stream the body into the cache entry as it is received. Once we've successfully cached the entire body, we create an index entry in the database. If any of these steps failed along the way, the cache entry is removed and the index is left untouched. Subsequent requests are checked for cache hits from the index. If a hit is found, we read just enough of the cache entry to inform WebContent of the status code and headers. The body of the response is piped to WC via syscalls, such that the transfer happens entirely in the kernel; no need to allocate the memory for the body in userspace (WC still allocates a buffer to hold the data, of course). If an error occurs while piping the body, we currently error out the request. There is a FIXME to switch to a network request. Cache hits are also validated for freshness before they are used. If a response has expired, we remove it and its index entry, and proceed with a network request.
2025-10-07 19:59:21 -04:00
}
Reference in a new issue Copy permalink