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

52 lines
1.9 KiB
C
Raw Permalink Normal View History

LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
/*
LibHTTP+LibWeb+RequestServer: Handle the Fetch API's cache mode If the cache mode is no-store, we must not interact with the cache at all. If the cache mode is reload, we must not use any cached response. If the cache-mode is only-if-cached or force-cache, we are permitted to respond with stale cache responses. Note that we currently cannot test only-if-cached in test-web. Setting this mode also requires setting the cors mode to same-origin, but our http-test-server infra requires setting the cors mode to cors.
2026-01-20 19:12:36 -03:00
* Copyright (c) 2025-2026, Tim Flynn <trflynn89@ladybird.org>
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/ByteString.h>
#include <AK/HashMap.h>
#include <AK/NonnullRefPtr.h>
#include <AK/RefCounted.h>
LibHTTP+LibWeb: Purge non-fresh entries from the memory cache Once a cache entry is not fresh, we now remove it from the memory cache. We will avoid handling revalidation from within WebContent. Instead, we will just forward the request to RequestServer, where the disk cache will handle revalidation for itself if needed.
2026-01-11 10:59:30 -03:00
#include <AK/Time.h>
LibWeb: Preserve file-backed HTTP cache bodies Carry response chunks through LibRequests and ResourceLoader as a ResponseData wrapper. A disk cache hit can retain its mapped storage, while ordinary streamed chunks still use borrowed bytes. Store completed memory cache entries as Core::ImmutableBytes. This lets mapped disk-cache responses stay file-backed while retained by the HTTP memory cache, instead of forcing another ByteBuffer copy.
2026-05-15 09:49:12 -03:00
#include <LibCore/ImmutableBytes.h>
LibHTTP+LibWeb+RequestServer: Handle the Fetch API's cache mode If the cache mode is no-store, we must not interact with the cache at all. If the cache mode is reload, we must not use any cached response. If the cache-mode is only-if-cached or force-cache, we are permitted to respond with stale cache responses. Note that we currently cannot test only-if-cached in test-web. Setting this mode also requires setting the cors mode to same-origin, but our http-test-server infra requires setting the cors mode to cors.
2026-01-20 19:12:36 -03:00
#include <LibHTTP/Cache/CacheMode.h>
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
#include <LibHTTP/Forward.h>
#include <LibURL/URL.h>
namespace HTTP {
class MemoryCache : public RefCounted<MemoryCache> {
public:
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 };
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
u32 status_code { 0 };
ByteString reason_phrase;
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+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
NonnullRefPtr<HeaderList> response_headers;
LibWeb: Preserve file-backed HTTP cache bodies Carry response chunks through LibRequests and ResourceLoader as a ResponseData wrapper. A disk cache hit can retain its mapped storage, while ordinary streamed chunks still use borrowed bytes. Store completed memory cache entries as Core::ImmutableBytes. This lets mapped disk-cache responses stay file-backed while retained by the HTTP memory cache, instead of forcing another ByteBuffer copy.
2026-05-15 09:49:12 -03:00
Core::ImmutableBytes response_body;
LibWeb: Preserve JS bytecode in memory cache Store JavaScript bytecode side data in the WebContent HTTP memory cache and replay it when serving cached responses. Also update an already-complete memory-cache entry when asynchronous bytecode cache generation finishes, so the first source-only response does not keep shadowing the disk-cache sidecar during same-process navigations. Keep the HTTP memory-cache backfill keyed with the request headers that populated the memory-cache entry, so Vary responses still receive their generated bytecode sidecar. Add LibHTTP coverage for round-tripping bytecode side data through a memory-cache entry, attaching it after the response body has already been cached, and matching Vary headers during updates. Add LibWeb coverage for preserving the memory-cache request headers when cloning responses.
2026-05-27 20:43:13 -03:00
Optional<Core::ImmutableBytes> javascript_bytecode_cache;
Optional<u64> javascript_bytecode_cache_vary_key;
LibHTTP+LibWeb: Purge non-fresh entries from the memory cache Once a cache entry is not fresh, we now remove it from the memory cache. We will avoid handling revalidation from within WebContent. Instead, we will just forward the request to RequestServer, where the disk cache will handle revalidation for itself if needed.
2026-01-11 10:59:30 -03:00
UnixDateTime request_time;
UnixDateTime response_time;
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
};
static NonnullRefPtr<MemoryCache> create();
LibHTTP+LibWeb+RequestServer: Handle the Fetch API's cache mode If the cache mode is no-store, we must not interact with the cache at all. If the cache mode is reload, we must not use any cached response. If the cache-mode is only-if-cached or force-cache, we are permitted to respond with stale cache responses. Note that we currently cannot test only-if-cached in test-web. Setting this mode also requires setting the cors mode to same-origin, but our http-test-server infra requires setting the cors mode to cors.
2026-01-20 19:12:36 -03:00
Optional<Entry const&> open_entry(URL::URL const&, StringView method, HeaderList const& request_headers, CacheMode);
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
LibWeb: Preserve JS bytecode in memory cache Store JavaScript bytecode side data in the WebContent HTTP memory cache and replay it when serving cached responses. Also update an already-complete memory-cache entry when asynchronous bytecode cache generation finishes, so the first source-only response does not keep shadowing the disk-cache sidecar during same-process navigations. Keep the HTTP memory-cache backfill keyed with the request headers that populated the memory-cache entry, so Vary responses still receive their generated bytecode sidecar. Add LibHTTP coverage for round-tripping bytecode side data through a memory-cache entry, attaching it after the response body has already been cached, and matching Vary headers during updates. Add LibWeb coverage for preserving the memory-cache request headers when cloning responses.
2026-05-27 20:43:13 -03:00
void create_entry(URL::URL const&, StringView method, HeaderList const& request_headers, UnixDateTime request_time, u32 status_code, ByteString reason_phrase, HeaderList const& response_headers, Optional<Core::ImmutableBytes> javascript_bytecode_cache = {}, Optional<u64> javascript_bytecode_cache_vary_key = {});
LibWeb: Preserve file-backed HTTP cache bodies Carry response chunks through LibRequests and ResourceLoader as a ResponseData wrapper. A disk cache hit can retain its mapped storage, while ordinary streamed chunks still use borrowed bytes. Store completed memory cache entries as Core::ImmutableBytes. This lets mapped disk-cache responses stay file-backed while retained by the HTTP memory cache, instead of forcing another ByteBuffer copy.
2026-05-15 09:49:12 -03:00
void finalize_entry(URL::URL const&, StringView method, HeaderList const& request_headers, u32 status_code, HeaderList const& response_headers, Core::ImmutableBytes response_body);
LibWeb: Preserve JS bytecode in memory cache Store JavaScript bytecode side data in the WebContent HTTP memory cache and replay it when serving cached responses. Also update an already-complete memory-cache entry when asynchronous bytecode cache generation finishes, so the first source-only response does not keep shadowing the disk-cache sidecar during same-process navigations. Keep the HTTP memory-cache backfill keyed with the request headers that populated the memory-cache entry, so Vary responses still receive their generated bytecode sidecar. Add LibHTTP coverage for round-tripping bytecode side data through a memory-cache entry, attaching it after the response body has already been cached, and matching Vary headers during updates. Add LibWeb coverage for preserving the memory-cache request headers when cloning responses.
2026-05-27 20:43:13 -03:00
void update_javascript_bytecode_cache(URL::URL const&, StringView method, HeaderList const& request_headers, u64 vary_key, Core::ImmutableBytes javascript_bytecode_cache);
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
private:
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_pending_entries;
HashMap<u64, Vector<Entry>, IdentityHashTraits<u64>> m_complete_entries;
LibHTTP+LibWeb: Store the in-memory HTTP cache without JS realms The in-memory HTTP Fetch cache currently keeps the realm which created each cache entry alive indefinitely. This patch migrates this cache to LibHTTP, to ensure it is completely unaware of any JS objects. Now that we are not interacting with Fetch response objects, we can no longer use Streams infrastructure to pipe the response body into the Fetch response. Fetch also ultimately creates the cache response once the HTTP response headers have arrived. So the LibHTTP cache will hold entries in a pending list until we have received the entire response body. Then it is moved to a completed list and may be used thereafter.
2025-12-21 10:58:55 -03:00
};
}
Reference in a new issue Copy permalink