ladybird/Libraries/LibHTTP/Cache/Version.h

/*
 * Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#pragma once

#include <AK/Types.h>

namespace HTTP {

// Increment this version when a breaking change is made to the cache index or cache entry formats.
static constexpr inline u32 CACHE_VERSION = 4u;

}
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 13:39:08 -03:00			`/*`
			`* Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>`
			`*`
			`* SPDX-License-Identifier: BSD-2-Clause`
			`*/`

			`#pragma once`

			`#include <AK/Types.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			`namespace HTTP {`
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 13:39:08 -03:00
			`// Increment this version when a breaking change is made to the cache index or cache entry formats.`
RequestServer: Store a couple of data hashes in disk cache entries We currently have a FIXME to validate cached data with a crc32. But this is sort of a non-starter, because we never actually have the cached data in-memory - we transfer it to the WebContent process via system calls, and it never reaches userspace in RequestServer. Chrome makes a bit of an educated gamble here. They assume cosmic bit blips are extremely unlikely, thus the cached data does not get verified with a hash. Instead, they store non-cryptographic hashes of some select fields, and they validate just those hashes. Here, we store a hash of the cache key in the cache header, and a hash of the cache header in the cache footer. With these validations, along with other validations already in-place, we can be reasonably sure we are not sending corrupt data to the WebContent process. 2025-11-20 17:12:05 -03:00			`static constexpr inline u32 CACHE_VERSION = 4u;`
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 13:39:08 -03:00
			`}`