dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibHTTP/Cache/CacheIndex.h

94 lines
3.2 KiB
C
Raw 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 20:59:21 -03: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 13:08:14 -03: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 20:59:21 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Error.h>
#include <AK/HashMap.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 12:04:59 -03:00
#include <AK/NonnullRawPtr.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 20:59:21 -03:00
#include <AK/Time.h>
#include <AK/Types.h>
#include <LibDatabase/Database.h>
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 16:13:23 -03:00
#include <LibHTTP/HeaderList.h>
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 15:10:27 -03:00
#include <LibRequests/CacheSizes.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 20:59:21 -03: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 12:04:59 -03: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 20:59:21 -03:00
// The cache index is a SQL database containing metadata about each cache entry. An entry in the index is created once
// the entire cache entry has been successfully written to disk.
class CacheIndex {
struct 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 12:23:56 -03:00
u64 vary_key { 0 };
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 20:59:21 -03:00
String 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 13:08:14 -03:00
NonnullRefPtr<HeaderList> request_headers;
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 12:04:59 -03:00
NonnullRefPtr<HeaderList> 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 20:59:21 -03:00
u64 data_size { 0 };
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 11:54:21 -03:00
u64 serialized_request_headers_size { 0 };
u64 serialized_response_headers_size { 0 };
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 20:59:21 -03:00
UnixDateTime request_time;
UnixDateTime response_time;
UnixDateTime last_access_time;
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 11:54:21 -03:00
u64 estimated_size() const
{
return data_size + serialized_request_headers_size + serialized_response_headers_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 20:59:21 -03:00
};
public:
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 11:35:44 -03:00
static ErrorOr<CacheIndex> create(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 20:59:21 -03: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 21:03:41 -03:00
ErrorOr<void> 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);
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 12:23:56 -03:00
void remove_entry(u64 cache_key, u64 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 19:53:00 -03:00
void remove_entries_exceeding_cache_limit(Function<void(u64 cache_key, u64 vary_key)> 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 12:23:56 -03:00
void remove_entries_accessed_since(UnixDateTime, Function<void(u64 cache_key, u64 vary_key)> on_entry_removed);
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 20:59:21 -03: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 12:23:56 -03:00
Optional<Entry const&> 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 20:59:21 -03: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 12:23:56 -03:00
void update_response_headers(u64 cache_key, u64 vary_key, NonnullRefPtr<HeaderList>);
void 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 20:59:21 -03: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 12:04:59 -03:00
Requests::CacheSizes 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 15:10:27 -03:00
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 14:25:14 -03:00
void set_maximum_disk_cache_size(u64 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 20:59:21 -03:00
private:
struct Statements {
Database::StatementID insert_entry { 0 };
Database::StatementID remove_entry { 0 };
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 19:53:00 -03:00
Database::StatementID remove_entries_exceeding_cache_limit { 0 };
RequestServer: Add a time parameter to the clear cache endpoint This allows removing cache entries last accessed since a provided timestamp.
2025-11-02 18:44:30 -03:00
Database::StatementID remove_entries_accessed_since { 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 12:23:56 -03:00
Database::StatementID select_entries { 0 };
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 18:09:35 -03:00
Database::StatementID update_response_headers { 0 };
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 20:59:21 -03:00
Database::StatementID update_last_access_time { 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 15:10:27 -03:00
Database::StatementID estimate_cache_size_accessed_since { 0 };
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 11:54:21 -03:00
Database::StatementID select_total_estimated_size { 0 };
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 20:59:21 -03: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 19:53:00 -03:00
struct Limits {
u64 free_disk_space { 0 };
u64 maximum_disk_cache_size { 0 };
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 21:03:41 -03:00
u64 maximum_disk_cache_entry_size { 0 };
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 19:53:00 -03: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 11:54:21 -03:00
CacheIndex(Database::Database&, Statements, 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 20:59:21 -03: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 12:23:56 -03:00
Optional<Entry&> get_entry(u64 cache_key, u64 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 19:53:00 -03:00
void delete_entry(u64 cache_key, u64 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 12:23:56 -03: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 12:04:59 -03:00
NonnullRawPtr<Database::Database> m_database;
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 20:59:21 -03:00
Statements m_statements;
LibHTTP: Use IdentityHashTraits for HashMaps keyed by the cache key The cache key itself is already an integral export of a SHA-1 hash of some request fields. We don't need to hash it again for these maps.
2026-02-24 10:03:52 -03:00
HashMap<u64, Vector<Entry>, IdentityHashTraits<u64>> m_entries;
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 19:53:00 -03:00
Limits m_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 11:54:21 -03:00
u64 m_total_estimated_size { 0 };
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 20:59:21 -03:00
};
}
Reference in a new issue Copy permalink