How cookies, query strings, and request methods affect caching
The URL path is only one part of an HTTP request. Cookies, query parameters, and the method can change who the visitor is, what content was requested, or whether data should be modified. POM Cache evaluates all three before reusing shared HTML.
Cookies: bypass rather than vary
POM Cache does not append cookie values to page filenames. It recognizes specific state-bearing families and bypasses the shared file:
| Cookie state | Reason for bypass |
|---|---|
| WordPress authentication | User, role, capability, private content, and admin UI can differ |
| Post password | Protected content may have been unlocked |
| Comment author | Comment form and visitor state can differ |
| WooCommerce session | Storefront state may belong to one shopper |
| WooCommerce cart hash/items | Cart-dependent markup can change |
The anonymous index.html stays available to requests without those cookies.
A separate application can introduce additional personalization cookies. POM Cache cannot infer their semantics; the integration and every upstream cache layer must exclude them deliberately.
Query strings: normalize only known tracking
Meaningful query state bypasses static HTML. Common examples include:
?s=coffee
?color=blue
?currency=EUR
?preview=truePOM Cache maintains a list of recognized attribution parameters, such as UTM, advertising click, and social referral identifiers. In PHP, it removes those names from the internal request URI. If nothing meaningful remains, the request can share the canonical path:
/menu/?utm_campaign=spring
→ canonical candidate: /menu/Mixed parameters remain dynamic:
/menu/?utm_campaign=spring&allergen=nuts
→ bypass because allergen changes the requestThe direct Apache rule uses its own stricter conditions and normally expects no query string. A tracking URL can therefore fall through to PHP while the canonical URL is served by Apache.
Methods: reads versus state changes
The PHP static contract accepts:
GETfor a normal response body;HEADfor the same response metadata without a body.
It rejects POST, PUT, and DELETE before early delivery and again before generation. Submitted form data is also non-cacheable.
Any native web-server or CDN rule must enforce the same safety outcome: only read methods may reach a static page file, and state-changing requests must continue to the application. Verify the effective deployed rule, not only the WordPress setting.
A compact test matrix
Use one already cached public URL:
| Request variation | Expected origin behavior |
|---|---|
Clean anonymous GET |
May serve index.html |
Anonymous HEAD |
May serve static headers, no body |
| WordPress login cookie | Bypass |
| Post-password cookie | Bypass |
| WooCommerce session/cart cookie | Bypass |
| Tracking-only query in PHP path | May use canonical entry |
| Content-changing query | Bypass |
POST, PUT, or DELETE |
Bypass |
JSON Accept header |
Must not receive HTML file |
Run the matrix against PHP first, then Apache, then the CDN. A correct PHP result cannot compensate for an unsafe response already returned upstream.
Do not test with secret values in logs
Record cookie names, not cookie values. Session and authentication values are credentials. Redact query parameters that contain personal data, access tokens, email addresses, or order references before sharing a diagnostic.
If a variation behaves unexpectedly, inspect Which requests are excluded and Caching and response headers to identify the answering layer.