http-cache

[HTTP Cache] API. Overall, this should look very familiar to users of the Core Cache API. The primary differences are: - HTTP `request`s and `response`s are used rather than relying on the user to encode headers, status codes, etc in `user-metadata`. - Convenience functions specific to HTTP semantics are provided, such as `is-request-cacheable`, `get-suggested-backend-request`, `get-suggested-write-options`, and `transaction-record-not-cacheable`. The HTTP-specific behavior of these functions is intended to support applications that match the normative guidance in [RFC 9111]. For example, `is-request-cacheable` returns `false` for `POST` requests. However, this answer along with those of many of these functions explicitly provide *suggestions*; they do not necessarily need to be followed if custom behavior is required, such as caching `POST` responses when the application author knows that to be safe. The starting points for this API are `lookup` (no request collapsing) and `transaction-lookup` (request collapsing). [HTTP Cache]: https://www.fastly.com/documentation/guides/concepts/edge-state/cache/cache-freshness/ [RFC 9111]: https://www.rfc-editor.org/rfc/rfc9111.html