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 by default. 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/Google's _gl linker parameter is also recognized. It carries attribution and session information for Google's browser-side tags without selecting different page content. POM Cache normalizes it internally and leaves the browser URL intact so those tags can still read it:
/shop/?_gl=google-linker-value
→ canonical candidate: /shop/Mixed parameters remain dynamic:
/menu/?utm_campaign=spring&allergen=nuts
→ bypass because allergen changes the request
/shop/?_gl=google-linker-value&orderby=price
→ bypass because orderby 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.
A plugin can explicitly register a small set of content-changing query variants through pom_cache_query_variant. Each approved combination receives its own cached response, separate from the canonical page. These variants use PHP delivery after plugins load, with an expiry chosen by the owning integration. Other parameters and values still bypass caching. Do not add content-changing parameters to the tracking list to achieve this; see the developer integration guide.
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 every other method, including POST, PUT, PATCH, DELETE and OPTIONS, 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 without an explicit integration | Bypass |
| Approved finite query variant | Separate PHP-served entry until expiry |
Any method other than GET or HEAD |
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.