wpsc_get_accept_header() ignores Accept header quality values (q-values)

[LorenDorez]

wpsc_get_accept_header() in wp-cache-phase2.php uses a naive str_contains() check to detect JSON requests. It does not parse Accept header quality values (q=) as defined in RFC 7231 §5.3.2. As a result, any request where application/json appears anywhere in the Accept header — even at low priority — is misclassified as a JSON request, preventing the cached file from being served and triggering a cache rebuild.

This is reproducible with New Relic Synthetics, which sends:

Accept: text/html,application/xhtml+xml,application/json;q=0.9,application/javascript;q=0.9,text/javascript;q=0.9,application/xml;q=0.9,text/plain;q=0.8,*/*;q=0.7

This is a valid HTML-preferring Accept header — text/html has implicit q=1.0 (highest priority), and application/json is explicitly deprioritised at q=0.9. However, WPSC treats the entire request as a JSON request and refuses to serve the cached file.

---

In wp-cache-phase2.php, wpsc_get_accept_header() (around line 533):

$accept = isset( $_SERVER['HTTP_ACCEPT'] ) ? strtolower( filter_var( $_SERVER['HTTP_ACCEPT'] ) ) : '';

foreach ( $accept_headers as $header ) {
    if ( str_contains( $accept, $header ) ) {
        $accept = 'application/json';
    }
}

if ( $accept !== 'application/json' ) {
    $accept = 'text/html';
}

The str_contains() check finds application/json anywhere in the raw Accept string without considering q-values. A request from New Relic Synthetics with application/json;q=0.9 (lower priority than text/html) is classified as a JSON request.

This misclassification has two downstream effects:

1. wp_cache_serve_cache_file() returns false immediately because wpsc_get_accept_header() !== 'text/html', so the cached file is never served.
2. get_wp_cache_key() appends -application/json to the cache key, meaning NR Synthetics requests generate and populate a separate cache bucket, triggering a fresh page build on every synthetic check.

---

Steps to reproduce

1. Enable WP Super Cache with Expert/SuperCache mode
2. Enabled Debug logging
3. Create a postman request that uses the above accept header
4. Observe in the debug log: wp_cache_serve_cache_file: visitor does not accept text/html. Not serving cached file. repeating on every synthetic check
5. Observe cache files being rebuilt on every NR Synthetics request

---

Expected Bahviour

When text/html is the highest q-value type in the Accept header, WPSC should classify the request as text/html and serve the cached file normally. The function should parse q-values and determine the highest-priority accepted type before comparing against the known JSON types.

---

Workarounds

The wpsc_accept_headers filter cannot easily fix this because wpsc_get_accept_header() caches its result via static $accept = 'N/A' and is called very early in the PHP request lifecycle — before functions.php is loaded — so any filter hooked from a theme or standard plugin loads too late.

A short-term workaround for those using WP Super Cache in PHP mode (not .htaccess/Expert mode) is to add via an mu-plugin:

<?php
// mu-plugins/fix-nr-accept-header.php
add_filter( 'wpsc_accept_headers', function( $headers ) {
    if ( ! empty( $_SERVER['HTTP_X_NEWRELIC_SYNTHETICS'] ) ) {
        return [];
    }
    return $headers;
} );

However this is NR-specific and does not fix the underlying q-value parsing issue that would affect other monitoring tools (Datadog Synthetics, Pingdom, UptimeRobot, etc.) with similar broad Accept headers.

---

Suggested Fix

wpsc_get_accept_header() should parse the Accept header properly, sorting types by q-value before comparing.

[donnchawp]

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: The Accept-header classifier treats any request mentioning a JSON type as a JSON request, ignoring RFC 7231 quality values, so HTML-preferring requests (e.g. monitoring tools) are misclassified and never served from cache.

Current behavior:
The function that classifies the request's Accept header (it normalizes to either text/html or application/json) does a plain substring match: if any of its known JSON media types (application/json, application/activity+json, application/ld+json, plus anything added via the wpsc_accept_headers filter) appears anywhere in the lowercased Accept string, the request is classified as application/json.

This ignores q= quality values. A valid HTML-preferring header such as:

Accept: text/html,application/xhtml+xml,application/json;q=0.9,application/javascript;q=0.9,text/javascript;q=0.9,application/xml;q=0.9,text/plain;q=0.8,*/*;q=0.7

(here text/html has implicit q=1.0, JSON is explicitly deprioritized at q=0.9) is misclassified as application/json. Consequences:

1. The cache-serving routine refuses to serve the cached file (it requires the classification to be text/html), so every such request is a cache miss.
2. The cache key includes the classification, so these requests populate a separate application/json bucket and trigger a fresh page build on every hit. Real-world trigger: New Relic Synthetics (and similar: Datadog/Pingdom/UptimeRobot) sending broad Accept headers.

Desired behavior:
The classifier must determine the request's preferred media type by parsing quality values per RFC 7231 §5.3.2, then classify:

• Parse each media range in Accept with its q value. A media range with no explicit q defaults to q=1.0.
• Determine the highest q-value present among (a) text/html and (b) the known JSON media types.
• Classify as application/json only when a known JSON type's q-value is strictly greater than the q-value that applies to text/html. Otherwise classify as text/html.
• Ties resolve to text/html (serve the cached HTML). This is the safe default: a request that accepts HTML at least as much as JSON should receive the cached page.
• Genuine JSON requests must still classify as application/json — e.g. Accept: application/json alone, or any header where a JSON type strictly outranks text/html.
• An empty/absent Accept header classifies as text/html (unchanged from today).
• text/html's effective q-value should also account for a wildcard */* only if text/html itself is not explicitly present — i.e. an explicit text/html;q=… takes precedence over */*. (Keep this simple; the goal is correct relative ranking of html vs json, not a full content-negotiation engine.)

Edge cases to handle without fatal errors:

• Malformed q-values (q=, q=abc, q=2, q=-1): treat as the default 1.0 or clamp into the valid 0.0–1.0 range; never error.
• Whitespace around media ranges and parameters.
• Mixed case (the header is already lowercased before comparison today; preserve that).

Key interfaces:

• The Accept-header classifier function (currently returns the string text/html or application/json, memoizes its result in a static, and applies the wpsc_accept_headers filter to the JSON type list). Its return contract is unchanged — still one of those two strings. Only the internal decision logic changes.
• The wpsc_accept_headers filter must continue to work: filtered/added types participate in the q-value comparison as JSON types.
• Callers that compare the result against text/html (cache serving) and that fold it into the cache key must not need changes.

Acceptance criteria:

• The New Relic Synthetics header above classifies as text/html.
• Accept: application/json (alone) classifies as application/json.
• Accept: text/html,application/json (both implicit q=1.0) classifies as text/html (tie → html).
• Accept: application/json,text/html;q=0.9 classifies as application/json (json strictly higher).
• Accept: application/ld+json;q=1.0,text/html;q=0.8 classifies as application/json, demonstrating filtered/extra JSON types still participate.
• Absent or empty Accept classifies as text/html.
• Malformed q-values do not cause a warning or fatal; the request is still classified deterministically.
• The wpsc_accept_headers filter still adds types that are honored by the new logic.
• The function remains free of dependencies on the theme or late-loaded plugins (it runs early in the request lifecycle) and keeps memoizing its result.
• Unit tests cover the cases above. (Note: a PHPUnit harness is being stood up in Make procedural cache functions unit-testable and seed initial PHPUnit tests #1051 — if it exists when this is picked up, add tests there; this function is a prime candidate since it is nearly pure. If the harness is not yet available, coordinate rather than block.)

Out of scope:

• Building a general HTTP content-negotiation library or supporting media types beyond the html-vs-json distinction this function exists to make.
• Changing the set of default JSON types or the wpsc_accept_headers filter contract.
• Changing how the result is used by callers (cache serving, cache key construction).
• The NR-specific X-Newrelic-Synthetics workaround mentioned in the issue — the q-value fix supersedes it.