1.3.0-beta4: suppress LSCache caching when BigPipe placeholders are present Cache-correctness fix from the 1.3.0-beta3 retest on portal-master. The retest reporter corrected an earlier miscall on Finding 7 (the auth-served-as-anonymous variant from the rc1 hand-back): the original canary protocol used authenticated-role-only test users with no visible per-user markup beyond what BigPipe streams, so the leak-detector saw identical responses regardless of whether the authenticated variant or the cached anonymous variant was served. The same operator hitting the canonical homepage as admin saw the anonymous-shape body; hitting a cache-busted URL produced the admin-shape body. Scenario (b) outcome: a real cache-correctness gap, not a downstream artifact of Finding 1. Root cause: BigPipe's Drupal core implementation resolves placeholders at streaming time inside PHP. LSWS serves cached responses without invoking PHP, so BigPipe never runs on cache hits and the placeholders stay unresolved. Authenticated content rendered via BigPipe (admin toolbar, user-account widgets, cached responses. What landed since 1.3.0-beta3 (commit 5593f00): - 86ed7f8: response subscriber scans the response body for `data-big-pipe-placeholder-id` markers. When detected, emits X-LiteSpeed-Cache-Control: no-cache to actively suppress LSWS-side caching. Active suppression is necessary because the HTTP Cache-Control is still public,max-age=N (the response is HTTP-cacheable in the abstract); a soft skip would let LSWS cache via its own header parsing anyway. - 39de4bc: three new unit tests on LscacheResponseSubscriberTest. testBigPipePlaceholderTriggersActiveNoCacheSuppression covers the suppression on the public branch. testBigPipePlaceholder SuppressesEvenInPrivateMode covers the private branch (BigPipe responses with user contexts that would otherwise qualify for private-cache emission still get suppressed because the private hit path also bypasses PHP). testNonBigPipeResponseEmitsPublic HeadersAsBefore is the regression guard verifying non-BigPipe responses continue to cache normally. - c5daa48: new docs section in htaccess-gotchas.md on the BigPipe interaction. Explains the streaming-vs-static incompatibility, documents the automatic suppression behaviour, and points operators with per-user content needs at the #type: 'lscache_esi' migration path with a before/after render-array example. - be1d4d9: ROADMAP records the beta4 cycle and the corrected Finding 7 attribution. Pure cache-correctness fix; no API contract changes. The HTTP 200 = SUCCEEDED mapping in the purger is unchanged. Operators who hit the beta3 BigPipe symptom can re-enable LSCache once on beta4 and re-run the amended canary protocol (admin role + editor role + anon, explicit checks for toolbar markup and BigPipe placeholder resolution). Deferred to 1.3.1 / 1.4.x (unchanged from beta3): post-purge sentinel verification flag, `everything` invalidation type, and the operator-experience polish items still in the queue. Soak target: clean re-test on the amended canary protocol from the env session; if clean, promotes straight to rc, then ~2 weeks soak, then 1.3.0 stable.