Skip to content

Nu mai servi o configurație de runtime învechită

Vitalie requested to merge 9_config-cache into main

/config.js se scrie la pornirea containerului și are conținut diferit de la un deploy la altul, dar stă la o adresă fixă, peste care se aplică TTL-ul de patru ore al zonei.

Măsurat pe live imediat după ce a plecat codul de analiză:

curl -D- https://hyperice.md/config.js
cf-cache-status: HIT
age: 1773
content-length: 70        # fișierul vechi, fără GA_MEASUREMENT_ID

Adică ID-ul ajunsese pe origin, dar la niciun vizitator. Cu cache-buster în URL originul răspundea corect — de aceea o verificare cu ?cb= ar fi spus „e live" în timp ce magazinul servea altceva.

De ce nu e de ajuns antetul

Motivul e deja scris în configurație, lângă favicon: TTL-ul de browser al zonei rescrie orice max-age mai mic. Așa că entrypoint-ul calculează amprenta fișierului pe care tocmai l-a scris și o pune în referința din index.html — o configurație schimbată devine o adresă nouă. no-store împiedică edge-ul să mai țină o copie a celei vechi între timp.

Verificat, nu presupus

Rulat în nginx 1.27 în container, cu scriptul real ca entrypoint:

  • /config.js răspunde cu Cache-Control: no-store
  • index.html servit conține src="/config.js?v=ef778fd8"
  • a doua rulare cu același mediu dă aceeași versiune și o singură referință
  • o configurație schimbată dă altă versiune
  • /assets/ își păstrează max-age=31536000, immutable — fixul nu se scurge peste fișierele care chiar pot fi cache-uite

Trei teste noi păzesc regula din configurație și amprentarea din script. Frontend 177 de teste în 21 de fișiere, typecheck și lint curate.

Refs #9 (closed)

Merge request reports