Explorerben következetesen oda rak vissza hol kattint az ember, ezért is idegesített ez a – látszólag véletlenszerű – viselkedés.

Ez így valójában egy erős usability hiba az oldalon, hosszabb találati listáknál nagyon frusztráló tud lenni, így nem árt odafigyelni rá. JS és CSS kukázások után végül a HTTP fejlécek vizsgálatába kezdtem, s meg is lett az ok.

Cache-Control: no-store, no-cache

Ez a dög valahogy bennemaradt az oldallal küldött fejlécekben, lehet hogy alapértelmezett webszerver beállítás, akkor pedig – hacsak a site szerveroldali részében felül nem bírálják – így marad.
Próbaképp átírva valami értékre, az a működés fogadott amit szerettem volna.

header("Cache-Control: max-age=300");

Valószínűleg emiatt a header miatt a FF valóban nem cachelt, s emiatt a Vissza gomb után újratöltötte az oldalt, ami viszont az oldal tetejére ugrott, mint megnyitáskor.

Viszon az, hogy ebbe viselkedésbe a Cache-Control HTTP fejléc hogyhogy nem szól bele IE, safari, opera, chrome böngészőkben… az más kérdés.

Amire ilyenkor viszont mindíg figyelni kell, az az, hogy a nagy cache fileok felzabálhatját a tárhelyed, ha nem ellenőrzöd ezeket a kéréseket rendesen. Megvallom, főleg front-end fejlesztőként bele se gondoltam pár dologba.

Mivel a CSS fileok szabadon elérhetőek kell legyenek a böngésző számára, lehetséges módosítani a lekérést, átrendezni a lekért fileok sorrendjét, duplikálni egy vagy több file nevét, s ezzel akár több ezer variációt is létrehozhatunk, ami simán betelítheti a tárhelyünket css fileokkal.

A hozzáférés szabályozása lehet komplikáltabb, figyelni a lekérések elemeit, sorrendiséget, vagy egyszerűbb, pl egy konkrét lekérdezést engedélyezni, ami lehet elég is, ritka az hogy egy sitehoz újabb css file-t adunk hozzá a napi karbantartás során. A lényeg az, hogy ilyen egyszerű dolgok is biztonsági kockázatot jelenthetnek egy oldal illetve szerver működése szempontjából.