Feature plan: Step 1 · Step 2 · Step 3 · Step 4

Debug mode: enabled

Original Query

I want to design high-traffic mode which uses the following structure:

• A directive in .htaccess set to check if an HTML file with the path exists, and just serve it (RewriteRule?).

• If a file does not exist, generate it and serve it; return to the previous step next time.

• It would sacrifice page freshness for performance.

Problem

Reduce repeated public-page rendering and PHP startup costs during traffic spikes while preserving access boundaries and a reliable way to refresh or withdraw content.

Option A — Apache serves an on-demand HTML cache

For explicitly eligible public pages, Apache serves identity-independent HTML even when the client has an initialized identity/session; misses reach PHP, which renders and publishes the same reusable public representation.

• Pros: matches the requested model; warm hits avoid PHP entirely; only visited pages need generation.

• Cons: Apache must enforce eligibility independently; cold requests can overwhelm generation; cached pages bypass PHP feature checks and visitor counting.

Option B — PHP serves an on-demand HTML cache

Keep the existing front-controller gate and extend its static-artifact path to generate missing pages and reuse them until refresh.

• Pros: preserves central access checks and application statistics; simpler integration with current feature state.

• Cons: every hit still starts PHP and checks configuration; less protection from PHP worker saturation.

Recommendation

Choose Option A, reusing existing public rendering and asset conventions, with an initial slice covering a small explicit set of public routes from first miss through warm hit, purge, and disabling the mode. The repository already has static releases and a PHP static-artifact fast path (public/.htaccess, src/ForumRewrite/Host/FrontController.php); this adds a separately controlled Apache bypass rather than weakening the current general routing rule.

• Eligibility: public instances only; GET/HEAD; initially no Authorization header or query string; explicit route allowlist whose HTML is safe to share across identities. Session-cookie presence alone must not disqualify a request: most legitimate clients immediately receive an initialized identity/session. Private, account-specific, and authorization-dependent routes retain ordinary routing. HEAD must return the same headers without a body.

• Representation: the user confirms pages currently have no identity-specific UI. Retain shared HTML; any identity UI should use a client-side placeholder, with authenticated operations separately authorized. Locally available state may populate it before first paint; server-dependent identity resolution must allow a neutral placeholder without blocking the entire page. Apache cannot infer privileges from an opaque session cookie; a shared public page must be appropriate for every viewer it serves.

• Publication: cache only successful identity-independent HTML, never a session-personalized miss response. Session initialization may require a separate live response; never persist or replay Set-Cookie headers in the shared cache. Use canonical route mapping, per-page generation coordination, and atomic publication; bound cache growth and cold-miss load. Rendering can succeed even if cache writing fails.

• Freshness: target roughly one to two minutes of routine content staleness. Cron regenerates cached pages into temporary files and atomically replaces each published file only when its replacement is ready; the existing page remains available throughout refresh. First-time misses still generate on demand. Coordinate cron and request-driven generation so overlapping work cannot publish an older result or restore an invalidated page. A failed refresh retains the last successful page and reports failure. This is a normal-operation target, not a guaranteed bound if cron fails or cannot finish its workload; expose failed/missed maintenance and provide manual refresh/purge. Access restrictions, removals/retractions, and relevant feature/configuration changes must withdraw affected cached content immediately rather than await cron. Disabling the Apache bypass is the recovery path.

• Control: use a dedicated .htaccess writer to switch between normal routing and high-traffic routing, coordinating Apache state with effective public/private configuration. Preserve unrelated deployment rules, serialize switches, and atomically replace the file with a complete version; failed writes must preserve the working configuration and report failure. Changing to private must disable direct serving first and prevent concurrent re-enablement; PHP-only flags cannot protect warm hits. Cache storage URLs must not provide an alternate access path.

• Toggle boundary: propose an operator setting and CLI backed by one reusable mode-switch service, with idempotent, serialized transitions and an observable effective mode, transition reason, and result. A future traffic/load controller must call this same service and respect its public-instance checks and operator override. Keep policy decisions separate from applying routing changes; mode changes and generation/publication must coordinate. Manual control must remain reachable outside cached routes. Traffic/load measurement, thresholds, hysteresis/cooldown, automatic activation, and any automatic deactivation are deferred to a follow-up cycle; automatic deactivation has not been requested. Define operator precedence before enabling automation.

• Operations: use web-server access logs for warm-hit traffic; retain assets referenced by cached pages; initially keep browser caching revalidating so server purge remains effective. Verify actual Apache hits, concurrent misses, bypasses, and public-to-private transitions before release.

• Refresh priority: read the latest configurable X lines of the sysop-provided access.log to rank a bounded queue by popularity within that sample. Invoking tail is optional; use a bounded end-of-file read rather than scanning the entire log. Log location, rotation, retention, and operational handling belong to the sysop; do not add application-managed log cursors or rotation recovery. Normalize and allowlist routes, deduplicate work, skip sufficiently fresh pages, and bound each run. Popularity ordering cannot guarantee every page stays within two minutes under sustained overload. Cache admission and eviction also need bounds.

• Generation metadata: embed a machine-readable UTC generation timestamp so each HTML artifact can self-identify its age and, when necessary, trigger a low-priority regeneration request. Deduplicate and rate-limit those requests, validate the canonical route, and let the server verify current cache age so old clients cannot repeatedly regenerate an already-refreshed page. The trigger schedules work without delaying the page response or granting publication authority. Generation time is distinct from source-data freshness; identify the content snapshot and renderer/cache generation as needed to reject obsolete publication. Keep scheduling metadata available without scanning every HTML file. A timestamp alone is not a publication lock or invalidation mechanism.

• Cold traffic: allow at most one generator per canonical page across cron and request handling, with a global generation concurrency limit, bounded waiting, and bounded admission of distinct routes. Serve an existing valid page during refresh. With no cached page and no available capacity, return a lightweight temporary-unavailable response with retry guidance; do not fall through to unlimited rendering. PHP request-worker saturation and arbitrary-URL floods still require host-level concurrency/rate controls; application rendering limits alone do not solve them.

• Failure scope: retain minimum recovery in this cycle: preserve working files on failed replacement, retain still-eligible stale pages on failed refresh, log failures, clean abandoned temporary files, bound waits/work/storage, and provide normal-mode recovery. Defer a broader failure-management system (dashboards, alerts, automated repair, and richer retry policies) to a separate proposed Railspike cycle; no separate cycle is started or approved here.

The writer's ownership boundary, host write permissions, Apache validation/recovery, configuration interlock, and compatibility of existing rendered pages with cross-identity reuse remain design questions for Step 2. Verify session initialization/resumption and identity-dependent interactions on both warm hits and misses. The existing PHP static resolver rejects all cookies, so it cannot be reused unchanged as the new eligibility policy. Retain a recoverable normal-routing configuration outside the public cache; mode changes must not depend on a cached control page. No application, deployment configuration, or test changes are authorized by this assessment.

Design refinement

• Request: consider a .htaccess writer for switching modes. Disposition: incorporated into Option A's recommendation as the mode-switch mechanism. Approval status: Step 1 revision awaiting review; no approval to advance or implement. Outcome: writer responsibilities and unresolved deployment constraints recorded above.

• Request: account for most legitimate clients immediately receiving an initialized identity/session. Disposition: replaced cookie-free eligibility with cross-identity public-representation eligibility; identity/session presence is distinct from a need for personalized HTML. Approval status: Step 1 revision awaiting review. Outcome: session-bearing traffic is part of the intended cache audience; shared rendering and live identity behavior require validation.

• Request: pages one or two minutes old, until the next cron job, are acceptable. Disposition: adopt a roughly one-to-two-minute normal-operation freshness target. Approval status: Step 1 revision awaiting review. Outcome: the initially proposed periodic expiry is superseded by background regeneration below; the freshness target remains.

• Request: cron should generate replacement pages and swap temporary files into place when ready, reducing cache misses. Disposition: replace cron-driven expiry with proactive regeneration and atomic per-page replacement while continuing to serve the previous version. Approval status: Step 1 revision awaiting review. Outcome: refresh creates no deliberate cache gap; first-time misses remain on demand, failed refreshes retain existing pages, and publication must coordinate with generation and invalidation.

• Request: retain shared pages, use client-side identity placeholders, prioritize cron using access-log popularity, consider internal timestamps, address cold traffic, and consider separate failure work. Disposition: incorporated the first five into the recommendation; propose separate broader failure-management work while retaining essential recovery in this slice. Approval status: Step 1 revision awaiting review; separate failure scope unapproved. Outcome: decisions and remaining capacity/first-paint limits recorded above.

• Request: use plain tail for access-log intake and leave other log operations to the sysop; let internal timestamps self-identify HTML and trigger low-priority regeneration; accept proposed cold-traffic handling. Disposition: simplified log intake and expanded timestamp purpose; retained cold-traffic limits as agreed. Approval status: these refinements are accepted direction; Step 1 as a whole still awaits approval. Outcome: supersedes application-managed rotation/cursor handling; regeneration triggers remain bounded and server-validated.

• Clarification: tail meant reading the latest X log lines, not requiring a particular executable. Disposition: implementation choice remains open; use a bounded recent-lines sample without persistent ingestion state. Approval status: Step 1 revision awaiting review. Outcome: supersedes the literal-command interpretation above.

• Request: explain how the mode is toggled. Disposition: proposed operator setting and CLI using one shared mode-switch service. Approval status: proposed interface, awaiting Step 1 review. Outcome: toggle boundary recorded above.

• Request: anticipate a near-term addition that measures traffic/load and automatically enables the mode. Disposition: retain a reusable switch service and observable state now; defer measurement and automatic activation to a separate follow-up cycle. Approval status: architectural direction recorded; follow-up implementation unapproved. Outcome: future automation can reuse the same safety checks and writer; override precedence and anti-flapping policy must be defined before activation.

Apache references: rewrite conditions and processing, rewrite termination flags.