[spip-dev] Cache et version statique

Dev
1

Encore une petite louche sur le cache, le dynamique et le statique,

dans votre modèle, qu'est-ce qui empêchait que les pages qui sont générés suivent une organisation sous la forme d'un arbre et donc finalement génère un site statique. Cela n'enlèverait rien à votre système éviterait l'écriture des inc_url.php3.

Du genre il y a des rubriques de 1er niveau
  + poetes
    - Beaudelaire
      article2.html
    - Verlaine
    - Rilke
  + ecrivains
    - Sartre
    - Woolf

Ainsi le cache aura cette organisation suivante, les URLs seront tu type

  /poetes/Beaudelaire/article2.html

Le fichier a été modifié ou il a besoin d'être regénéré, pas de problème puisqu'on sait exactement ou il est. Quelle est la différence par rapport à une distribution aléatoire dans des répertoires ? Qu'est-ce qui me manque au passage ?

2

Salut Karl,

C'est ce que fait Fil sur le Diplo. Il a indiqué (à titre d'exemple) le fichier d'URL qu'il utilise:
http://rezo.net/spip-dev/contrib/Philippe.Riviere/inc-urls-diplo.php3

Il y a cependant 2 inconvénients pour qu'on livre une telle solution dans SPIP standart:

- cela réclame des rewrite_rules (soit dans la config d'Apache, soit dans un fichier local .htaccess); et ça, c'est pas du tout évident chez tous les hébergeurs;

- on se retrouve avec des URLS liées à la position de l'article dans les rubriques; d'où, pour le coup, l'apparition d'"erreurs 404" (pour ainsi dire) quand tu déplace un article dans la structure du site. En effet, si ton article2 passe dans Sartre, son URL change (/ecrivains/Sartre); alors qu'avec le système (simple) actuel, quelle que soit sa position dans la structure, l'article2 conserve toujours le même URL.

Enfin (mais là, je n'irais pas le jurer), il me semble que cela pose un problème avec les squelettes et leurs liens relatifs. En effet, si tu inclues des images dans le squelette article.html, les liens relatifs dans /poetes/Beaudelaire/... ne fonctionnent plus si tu fais un article dans /ecrivains/XXesiecle/Sartre/... (puisqu'il y a un niveau supplémentaire).

Sans compter, enfin, qu'il faudrait ajouter une "case" du formulaire pour indiquer le nom symbolique des rubriques (celui utilisé dans l'URL, et très certainement différent et plus simple que le nom/titre de la rubrique - dans uZine, la rubrique "Internet, faites-le vous-même" ne va certainement pas donner une adresse en "/webindependantwebcitoyen/internetfaiteslevousmeme"). Du coup ça introduit un élément "technique" dans l'espace privé, qui n'est censé gérer que de l'éditorial (OK, l'URL c'est pas bien méchant; mais comme on s'est vraiment battus avec nos tendances naturelles pour tout ça reste aussi simple que possible...).

Bref bref bref, SPIP le permet, mais la complexité que cela induit doit certainement (à moins qu'on trouve une solution simple) faire que cela reste une option. Quand Fil aura le temps, peut-être qu'une doc technique sur le sujet pourra être utile.

Amicalement,
ARNO*

3

@ Karl Dubost (karl@la-grange.net) :

finalement génère un site statique. Cela n'enlèverait rien à votre
système éviterait l'écriture des inc_url.php3.

On y est presque : le fichier caché est stocké sous sa forme d'uri
(transcodé de manière à ne pas avoir de problème avec les / , les " ", les ?
et autres joyeusetés). On répartit les caches très simplement via un hash
histoire de ne pas avoir trop de fichiers au même répertoire, mais c'est
tout. Changer cela serait très facile (deux fonctions à modifier).

Du genre il y a des rubriques de 1er niveau
  + poetes
    - Beaudelaire
      article2.html
    - Verlaine
    - Rilke
  + ecrivains
    - Sartre
    - Woolf

Ainsi le cache aura cette organisation suivante, les URLs seront tu type

  /poetes/Beaudelaire/article2.html

Le fichier a été modifié ou il a besoin d'être regénéré, pas de
problème puisqu'on sait exactement ou il est. Quelle est la
différence par rapport à une distribution aléatoire dans des
répertoires ? Qu'est-ce qui me manque au passage ?

Juste la gestion des passages de paramètres : si tu appelles
article.php3?id_article=7, où stockes-tu ton fichier cache ?

Dans inc-urls.php3 se trouvent les fonctions qui font les conversions
URI <-> id_article ; l'exemple donné des inc-urls-diplo montre que ce n'est
pas un modèle unique.

Mais il y a sûrement des tas de manière d'améliorer le cache :wink:

-- Fil

4

@ Arno* (arno@scarabee.com) :

Enfin (mais là, je n'irais pas le jurer), il me semble que cela pose
un problème avec les squelettes et leurs liens relatifs. En effet, si
tu inclues des images dans le squelette article.html, les liens
relatifs dans /poetes/Beaudelaire/... ne fonctionnent plus si tu fais
un article dans /ecrivains/XXesiecle/Sartre/... (puisqu'il y a un
niveau supplémentaire).

Oui, j'oubliais : le squelette est indépendant de la position de l'article
dans l'arborescence (sauf contrordre explicite du webmaster, via les
squelette-65.html), donc comment gères-tu les liens vers les images, les
liens internes (vers les rubriques, les autres articles, les mots-clés,
etc.? Pour le faire bien c'est très délicat et au-dessus des moyens de
l'utilisateur moyen de SPIP. Un usage plus "pro" est possible, comme le
prouve mon inc-urls-diplo.php3

Mais Karl parlait de l'arborescence du CACHE/ je crois.

Sans compter, enfin, qu'il faudrait ajouter une "case" du formulaire
pour indiquer le nom symbolique des rubriques (celui utilisé dans

Oui, j'utilise, pour cela, le champ "descriptif", car sa présence dans
l'espace interne correspond bien à son utilisation en tant que code d'URI.

-- Fil

5

Hello,

On y est presque : le fichier caché est stocké sous sa forme d'uri
(transcodé de manière à ne pas avoir de problème avec les / , les " ", les ?
et autres joyeusetés). On répartit les caches très simplement via un hash
histoire de ne pas avoir trop de fichiers au même répertoire, mais c'est
tout. Changer cela serait très facile (deux fonctions à modifier).

Mmmh oui sauf que l'argument avancé par Arno me semble capital :
tout changement dans la structure des rubriques entraîne la
caducité des URLs. C'est quand même plutôt chiant.

D'autre part, ce système serait assez difficile à adapter sur
les hébergeurs qui brident la création de répertoires en PHP.
(genre Freedom2Surf).

Enfin, tout le monde n'a pas envie de ce type de structure.
Ne serait-ce que pour la concision des URLs.

a+

6

Attention une URI est quelquechose qui ne change pas ou plutôt qui ne devrait pas changer. Cela ne veut pas dire que l'information ne pas se déplacer ou changer de rubriques, etc. Mais une URI devrait être tout le temps vivante.
  Voir: -> http://www.w3.org/Provider/Style/URI

Ensuite if ne faut pas confondre une URI qui pointe vers une ressource et cette ressource qui est un fichier qui peut se trouver n'importe où. En cela, votre système de cache est tout à fait logique. Je disais juste de modifier le système de CACHE de façon à le rendre plus lisible et pourquoi pas dans ce cas à respecter une URI.

La ressource est une donnée stockée à un endroit précis, cette ressource peut tout à fait être une extraction d'une base de données ou un fichier statique quelque part dans le filesystem. Pourquoi je me bats tant pour le statique car c'est plus efficace et lorsque le site devient gros peu importe si les scripts de génération sont foireux car le fichier statique lui est envoyé très rapidement. Ceci est très utile notamment quand le site est "sucé" par Google par exemple.

Donc je précise un peu plus et je passe à la couche HTTP. Quand on fait une requête HTTP à un serveur web, celui renvoie des informations.

un bon exemple sur la page suivante http://www.raubacapeu.net/people/yves/2001/05/13/weblog.html

Une information très importante est
Content-Location: http://www.raubacapeu.net/people/yves/2001/05/10/weblog.html

Cette variable du HTTP header précise la source du contenu. Donc imaginons, plusieurs cas (celui-ci est un peu idiot, mais c'est pour illustration)

  + Sartre/
    - auteur.html
  + Verlaine/
    - auteur.html

dans mon navigateur, je fais la requête
  http://www.example.org/Sartre/auteur.html

Le serveur renvoie dans le HTTP header, l'information

Content-Location: http://www.example.org/Verlaine/auteur.html

Et bien le contenu qui sera affiché à l'écran sera celui de l'auteur Verlaine avec l'URI de Sartre. Donc les URIs restent toujours valides.

EN PHP http://www.zend.com/manual/function.header.php

HTTP Protocol -> http://www.ietf.org/rfc/rfc2616.txt
Un autre principe important du protocole HTTP est le redirect permanent ou temporaire.
  Code 301 : déplacement permanent de la ressource vers une autre URI
  Code 302 : déplacement temporaire vers une nouvelle URI

Est-ce que mon explication est claire ou est-ce que c'est trop technique ?

7

Re-hello,

Karl Dubost wrote:

Cette variable du HTTP header précise la source du contenu. Donc
imaginons, plusieurs cas (celui-ci est un peu idiot, mais c'est pour
illustration)

        + Sartre/
                - auteur.html
        + Verlaine/
                - auteur.html

dans mon navigateur, je fais la requête
        http://www.example.org/Sartre/auteur.html

Le serveur renvoie dans le HTTP header, l'information

Content-Location: http://www.example.org/Verlaine/auteur.html

Et bien le contenu qui sera affiché à l'écran sera celui de l'auteur
Verlaine avec l'URI de Sartre. Donc les URIs restent toujours valides.

??? Je ne comprends pas comment ça marche ni ce que cela fait.
Si je prends un fichier a.php3, que je mets au début l'instruction
<? Header ("Content-Location: http://127.0.0.1/b.php3&quot;\); ?>,
et que je charge a.php3 dans mon navigateur, c'est pourtant le contenu
de a.php3 qui s'affiche avec l'URL de a.php3, ni le navigateur ni
le serveur (Apache 1.3.x sous Windows) ne semblant tenir compte du
header que j'ai ajouté. Donc, à quel niveau ce header est-il reconnu
et utilisé ?

Accessoirement, pouvoir gérer les anciennes URL implique de garder un
historique, ce qui n'est pas forcément simple ni souhaitable...

Amicalement

Antoine.

8

??? Je ne comprends pas comment ça marche ni ce que cela fait.
Si je prends un fichier a.php3, que je mets au début l'instruction
<? Header ("Content-Location: http://127.0.0.1/b.php3&quot;\); ?>,
et que je charge a.php3 dans mon navigateur, c'est pourtant le contenu
de a.php3 qui s'affiche avec l'URL de a.php3, ni le navigateur ni
le serveur (Apache 1.3.x sous Windows) ne semblant tenir compte du
header que j'ai ajouté. Donc, à quel niveau ce header est-il reconnu
et utilisé ?

Il te manque une partie, actuellement ton serveur te renvoie dans les Headers un code 200 OK donc pour lui, il n'y a pas d'autres contenus à aller chercher. Donc imaginons que c'est un contenu déplacer de façon permanente, il faut renvoyer un code 301...

Donc essaye cela

<? Header ("HTTP/1.1 301 OK"); ?>
<? Header ("Content-Location: http://127.0.0.1/b.php3&quot;\); ?>

Surprise !!!

Accessoirement, pouvoir gérer les anciennes URL implique de garder un
historique, ce qui n'est pas forcément simple ni souhaitable...

Avoir un glossaire des URIs sur le mode de Frontier peut-être très agréable dans certains cas, justement et très pratique, quelquechose du genre

<gloss>
  <entrygloss>Antoine Pitrou</entrygloss>
  <urigloss>mailto:pitrou@free.fr</urigloss>
</gloss>

<gloss>
  <entrygloss>SPIP</entrygloss>
  <urigloss>http://www.uzine.net/rubrique91.html&lt;/urigloss&gt;
</gloss>

De plus cela permet d'imaginer un système de parsing fort judicieux que Frontier a mis en oeuvre.

Dans ton document, tu veux créer un lien spécifique vers un endroit de ton site ou ailleurs.

  Tu fais "SPIP" dans le texte que tu tapes dans le formulaire.
  et hop ton parser remplace cela par

  <a href="http://www.uzine.net/rubrique91.html&quot;&gt;SPIP&lt;/a&gt;

9

Grossière erreur... que tout le monde a vu...

<? Header ("HTTP/1.1 301 Moved Permanently"); ?>
<? Header ("Content-Location: http://127.0.0.1/b.php3"); ?>

10

Il te manque une partie, actuellement ton serveur te renvoie dans les
Headers un code 200 OK donc pour lui, il n'y a pas d'autres contenus
à aller chercher. Donc imaginons que c'est un contenu déplacer de
façon permanente, il faut renvoyer un code 301...

Donc essaye cela

<? Header ("HTTP/1.1 301 OK"); ?>
<? Header ("Content-Location: http://127.0.0.1/b.php3&quot;\); ?>

Surprise !!!

Surprise, heu, ça ne marche pas ;)) Je récupère toujours le contenu
de la page appelée et non de celle vers laquelle le content-location
redirige.

<?

Header ("HTTP/1.1 301 Moved Permanently");
Header ("Content-Location: http://127.0.0.1/spip/article.html&quot;\);

[etc.]

Précision : le brouteur est Netscape 4.7.

a+

Antoine.

11

pas normal que cela ne marche pas, moi cela marche très bien...

Tu peux faire les opérations suivantes

% telnet 127.0.0.1 80

GET /a.php3 HTTP/1.1
Host: 127.0.0.1

deux retours chariot après le Host très important... et voir ce qui donne comme header...

12

Pas exactement un telnet mais :
<?
  $http = @fsockopen("127.0.0.1", 80);
  @fputs($http, "GET /crypt.php3 HTTP/1.1\nHost: 127.0.0.1\n\n");
  while (!feof($http)) {
    $s = fgets($http, 16384);
    echo "$s<br>";
    flush();
    if (!trim($s)) break;
  }
?>

Donne :

HTTP/1.1 301 Moved Permanently
Server: Apache/1.3.17 (Win32) PHP/4.0.4pl1
X-Powered-By: PHP/4.0.4pl1
Content-Location: http://127.0.0.1/spip/article.html
Transfer-Encoding: chunked
Content-Type: text/html

13

D'abord, merci à Arno qui a trouvé ce qui n'allait pas dans
l'installation Multimania : le sous-répertoire d'install
n'était pas détecté pour le chemin absolu du htpasswd.

Bon, mais vous savez quoi ? Quand on utilise la fonction mail()
chez Multibidule, la base MySQL devient injoignable... sic !
Ca fait des tas d'erreurs MySQL dans l'espace privé quand
on essaie d'envoyer le mail des nouveautés. De plus, comme
la mise à jour de la base de données pour signaler que le
mail a été envoyé, est effectuée après l'envoi du mail,
elle échoue, et donc le mail est envoyé à chaque passage
sur l'espace privé et ainsi de suite.

Marrant, non ?

14

Bon, mais vous savez quoi ? Quand on utilise la fonction mail()
chez Multibidule, la base MySQL devient injoignable... sic !
Ca fait des tas d'erreurs MySQL dans l'espace privé quand
on essaie d'envoyer le mail des nouveautés. De plus, comme
la mise à jour de la base de données pour signaler que le
mail a été envoyé, est effectuée après l'envoi du mail,
elle échoue, et donc le mail est envoyé à chaque passage
sur l'espace privé et ainsi de suite.

- C'est mail qui fait planter? Purée, elle est pas mal, celle là. Bon, donc faut désactiver les fonctions de mail chez Niania (mais p'têt que tu l'as déjà fait).

- Pour l'envoi répété, c'est pour cela que j'ai ajouté le test $db_ok avant d'envoyer le mail. Ca déconne quand même?

Faudrait passer la 1.0.2 en DISTRIB, non? Elle corrige tout de même pas mal de bugs.

ARNO*

15

ARNO* wrote:

- C'est mail qui fait planter? Purée, elle est pas mal, celle là.
Bon, donc faut désactiver les fonctions de mail chez Niania (mais
p'têt que tu l'as déjà fait).

- Pour l'envoi répété, c'est pour cela que j'ai ajouté le test $db_ok
avant d'envoyer le mail. Ca déconne quand même?

Faudrait passer la 1.0.2 en DISTRIB, non? Elle corrige tout de même
pas mal de bugs.

Un peu de patience :wink: J'ai une solution pour le mail chez Multimoche.
J'utilise la fonction register_shutdown_function(), qui permet
d'exécuter une fonction à la fin de l'exécution du script. La fonction
que j'enregistre envoie tous les mails empilés durant l'exécution
du script. Ca a l'air de marcher. (évidemment il faut utiliser la
fonction envoyer_mail(), non mail() directement, d'où l'intérêt
de la dite fonction...)

a+

16

Coucou,

Bon, ça y est, j'ai mis à jour la 1.0.2. Il reste
à attendre que les zip soient générés, pour les
mettre dans DISTRIB.

Pour infos, les modifs principales sont dans inc_mail
et inc_version. A noter que dans ce dernier, j'ai
commencé à centraliser les infos de versions (hébergeur,
OS, fonctions PHP...), donc ce serait bien de continuer
dans cette voie. De même, dans inc_mail, la fonction
envoyer_mail() prend en compte le cas Multimania, sûrement
un jour le cas Online et peut-être d'autres, donc c'est
bien de l'utiliser (il reste un mail() dans inc-public).

Il faudra faire pareil avec le chargement HTTP (j'ai
l'impression d'avoir déjà dit ça... ;-)).

a+

Antoine.

17

Ca c'est intéressant, il y a quelquechose qui ne va pas dans l'implémentation HTTP de Apache sur Windows.

Ton navigateur n'a pas grand chose à voir, cela se passe au niveau du server. :slight_smile:
je vais voir si on peut creuser la question car je t'assure que cela marche très bien chez moi par exemple.

18

Bon tout d'abord, le script doit se trouver sur la première ligne et commencer au premier caractère. D'autre part, peut-être qu'un "exit" peut aider.

Try again...

<?
Header ("HTTP/1.1 301 Moved Permanently");
Header ("Content-Location: http://127.0.0.1/spip/article.html");
exit;
?>

Si cela ne marche toujours avoir les logs du serveur.

19

Hello,

Non ça ne marche toujours pas. J'ai essayé sur Altern.com
(Apache 1.3.12 sous Linux), ça ne marche pas non plus.

Voici le log Apache en local pour la dite requête :
127.0.0.1 - - [06/Jul/2001:14:18:39 +0200] "GET /crypt.php3 HTTP/1.0" 301 0

Rien dans le error.log.

Quelque chose me titille : quand on modifie des headers via PHP,
le serveur doit-il faire autre chose que de simplement les
transmettre au client ? Ca me semble douteux, non ?

a+

Antoine.

Karl Dubost wrote:

20

Oui j'étais en train de travailler dessus... En effet tu as raison, on modifie l'information parce-que c'est important mais il faut quand même lui envoyer le fichier, il manquait le include.

Et double bêtise de ma part...

Header ("HTTP/1.1 200 OK");
Header ("Content-Location: http://127.0.0.1/test/retourcontent.html");
include ("http://127.0.0.1/test/retourcontent.html");

voici l'instruction, on envoie bien un 200 puisque que l'on va recevoir le fichier.

Par contre, il faudrait envoyer un 301 avec un Location et non pas un Content-Location... grossière erreur de ma part comme je le disais.

:slight_smile: