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.
14 lines
417 B
CMake
14 lines
417 B
CMake
set(TEST_SOURCES
|
|
TestCacheUtilities.cpp
|
|
TestHSTSPolicy.cpp
|
|
TestHSTSPreloadData.cpp
|
|
TestHTTPUtils.cpp
|
|
)
|
|
|
|
foreach(source IN LISTS TEST_SOURCES)
|
|
ladybird_test("${source}" LibWeb LIBS LibHTTP)
|
|
endforeach()
|
|
|
|
ladybird_test("TestCacheIndex.cpp" LibWeb LIBS LibHTTP LibDatabase)
|
|
ladybird_test("TestDiskCache.cpp" LibWeb LIBS LibHTTP LibURL)
|
|
ladybird_test("TestMemoryCache.cpp" LibWeb LIBS LibHTTP LibURL)
|