Configure request headers used in cache keys

[maxschmeling]

Summary

• add query-level cache_key_request_headers configuration for HTTP queries
• always retain Authorization and Cache-Control, merging additional query header names case-insensitively
• make get_cache_key_request_headers() part of HttpQueryInterface and have QueryRunner consume the query-owned policy directly
• carry the resolved list in one internal request header used consistently by cache lookup, storage, and logging
• strip the internal metadata before outbound dispatch and before storing the request in the cache entry
• configure Shopify’s built-in queries to include the storefront access-token header
• document the cache-isolation security risk, query-only configuration, and the direct-interface implementation requirement

Security

Remote Data Blocks does not include every request header in cache keys. If a custom header changes authentication, authorization, tenancy, or returned data, every query that uses it must list that header in cache_key_request_headers; otherwise requests with different security contexts can share a cached response.

Headers configured on a data source are not added automatically. The documentation calls this out prominently, including the cross-request and cross-user risk with persistent object caching. The built-in Authorization and Cache-Control defaults cannot be removed.

Compatibility

Direct implementations of HttpQueryInterface must implement get_cache_key_request_headers(). Returning [] uses only the built-in defaults. The extending guide includes an upgrade example.

Testing

• npm run format:check
• npm run lint:php
• npm run lint:js
• npm run check-types
• npm test (596 PHP tests / 1,374 assertions; 76 JavaScript tests)
• npm run build
• git diff --check

[github-actions]

Test this PR in WordPress Playground.

[chriszarate]

Cache poisoning is still possible in the future. The vary headers passed to the constructor ([]) and the ones used in get_object_cache_key_from_request are different. That is why I suggested porting the code from GreedyCacheStrategy and no longer extending it. I don't think we can honor its contract.

[maxschmeling]

Yeah, you're right, it's fine now but not safe for the future.

Copied the implementation here 1cde10a

Small tweak here: 9ae5731

Testing and checking now