These tests cover HTTP-specified behaviours for caches, primarily from RFC7234, but as seen through the lens of Fetch.
A few notes:
By its nature, caching is optional; some tests expecting a response to be cached might fail because the client chose not to cache it, or chose to race the cache with a network request.
Likewise, some tests might fail because there is a separate document-level cache that's ill-defined; see this issue.
Partial content tests (a.k.a. Range requests) are not specified in Fetch; tests are included here for interest only.
Some browser caches will behave differently when reloading / shift-reloading, despite the
cache mode staying the same.
At the moment, Edge doesn't appear to using HTTP caching in conjunction with Fetch at all.
Each test run gets its own URL and randomized content and operates independently.
Each test is an an array of objects, with the following members:
name- The name of the test.
requests- a list of request objects (see below).
Possible members of a request object:
[header_name_string, header_value_string]arrays to emit in the request.
[number, string]array containing the HTTP status code and phrase to return.
[header_name_string, header_value_string]arrays to emit in the response. These values will also be checked like expected_response_headers, unless there is a third value that is
false. See below for special handling considerations.
["cached", "not_cached", "lm_validate", "etag_validate", "error"]
response_statuswill be used; if that is not set, 200 will be used.
[header_name_string, header_value_string]representing headers to check the request for.
[header_name_string, header_value_string]representing headers to check the response for. See also response_headers.
response_bodywill be checked if present and non-null; otherwise the response body will be checked for the test uuid (unless the status code disallows a body). Set to
nullto disable all response body checking.
Some headers in
response_headers are treated specially:
See the source for exact details.