Version 20 — Novembre 2018 — JLuc
inclure/xray_marqueur_session
.-* ANALYSER : Le talon des caches sessionnés d’un squelette occupe le même espace (index de cache) que le cache non sessionné de ce squelette (pas de suffixe _). Or ils ne sont pas compatibles entre eux. C’est soit l’un, soit l’autre puisque leurs valeurs d’invalideurs[session] sont différentes (not set = non sessionné ; et vide = marqueur de sessionnement ).
- Une fois le talon créé, c’est le cache sessionné sans auth (avec suffixe _$) qui est également utilisé par la suite en guise de cache non sessionné. Mais quid si ça se passe dans l’autre sens ?
- Le talon n’est créé que s’il n’y a pas déjà un cache de même index. Mais s’il y en a déjà un, ce pourrait être lui-même ou le cache non sessionné de même emplacement. Donc, si le cache non sessionné est créé avant le premier cache sessionné, il n’y aura pas de talon, mais un cache non sessionné. Ce n’est pas grave pour l’écriture des caches sessionnés par creer_cache
(car l’existence du talon est seulement testée pour savoir s’il faut le créer ou non), mais pour la lecture par public_cacher
, c’est lui ( talon ou non sessionné) qu’on récupère d’abord, et c’est seulement s’il est sessionné (cas d’un vrai talon) qu’on cherche ensuite le cache sessionné... ce qui ne se passera donc pas si à la place du talon, un cache non sessionné a d’abord été écrit.
- Visiblement SPIP suppose qu’un squelette ne peut être à la fois sessionné dans certains contextes de compilation, et non sessionné dans d’autres contextes. Est-ce que cette supposition est justifiée : ne peut il à la fois y avoir un cache non sessionné et un cache sessionné pour un même squelette ?? Il semblerait que pourtant que ça soit possible, notamment car les boucles {id_auteur}
semblent contaminantes (point à vérifier plus précisément) et que, placées dans une autre noizette, elles contamineraient même un cache non sessionné (forceraient son sessionnement). Ça se passerait alors ainsi :
1) Cache vidé. Soit une noisette N non sessionnée. Son identifiant de cache est NNN. Ce serait aussi l’identifiant de cache du talon dans les cas où elle sessionnée.
2) Cette noisette est d’abord inclue dans un contexte non contaminant, le cache non sessionné est donc créé : NNN. Ça baigne.
3) Cette noisette est ensuite inclue dans un contexte contaminant avec un internaute logé. La lecture du cache NNN indique qu’elle n’est pas sessionnée, et c’est donc ce cache non sessionné qui est lu. La contamination a ainsi été annulée !
A priori, ça ne cause pas de problème, sauf si la contamination est justifiée (c’est un autre point à étudier) et qu’il faut réellement sessionner les caches contaminés ! Et de plus, les caches sessionnés par contamination ont été créés mais ne sont jamais utilisés.
- TODO : vérifier le phénomène de contamination et vérifier qu’on peut créer à la fois un cache non sessionné parfois et sessionné parfois. Le problème est peut être juste cette contamination.
{id_auteur}
contaminantes :
C’est critique. Il faut absolument éviter ces boucles.
ANALYSE : Est-ce que ça se passe toujours ou c’est lié aussi à d’autres conditions ? Où ça se passe t il dans le source ? Pourquoi ?
session=''
et lastmodified
. Les talons ne sont pas des caches de squelette, mais des marqueur de sessionnage : ils servent uniquement à indiquer que les caches de ce squelette sont sessionnés (cf source de creer_cache. Et alors, c’est un autre cache qui contient le contenu et les métadonnées du squelette : celui avec le suffixe d’identifiant de session.Du coup, il n’est pas possible d’avoir un squelette parfois sessionné et parfois non sessionné selon l’endroit où il est appelé : il sera toujours considéré comme sessionné.
Il y a autant de talons qu’il y a de couples (squelette, contexte). Pour chacun de ces talons, il y a autant de caches qu’il y a de sessions.
Xray propose des boutons pour, à partir d’un cache sessionné, accéder à la liste de tous les caches ayant le même talon.
ANALYSE : Comment est gérée l’arrivée d’un cache non sessionné alors qu’il fut sessionné avant ?
spip.php?page=unepage
:
...8b79-gis_json/spip
pour le cache de gis_json.html
...928-compte/spip
...f921a-saisies.css/spip
...fe22-mestrucs/spip
...a40f-backend/spip
ANALYSE : cf generer_nom_fichier_cache dans memoization/public/cacher : ça vient de $page['contexte_implicite']
['cache'].
Toutes ANALYSE : toutes les pages appelées directement y sont elles ? Y a t il du coup 2 caches (identiques ?) : l’un pour l’appel via ?page= et l’autre (sans suffixe /spip) pour l’appel via INCLURE ?