Test de la mise à jour de mx google sitemaps

[gowap]

Je comprends toujours rien

1) je sais parfaitement ce qu'est une feuille xsl
2) je fais la difference entre un fichier zip et un fichier gzip (.gz)
3) je fais la difference entre un fichier physique gzip et une page web transferée du serveur vers le client avec la compression gzip des pages active

les navigateurs sont donc capable de le décompresser à la volée, que ce soit parce que le header d'une page dynamique leur ait indiqué, ce qu'il se passe si on affiche une page du module, ou parce que l'extension .gz (pas zip) se trouve à la fin d'un nom de fichier physique.

Le navigateur n'affiche et ne decompresse quelque chose que lorsque l'on fait de la transmission de page avec la compression gzip active.
S'il s'agit d'un fichier, ex : http://switch.dl.sourceforge.net/source ... .21.tar.gz il ne va rien afficher et il va le télécharger.
On en revient a ce que je ne comprends pas :
Pourquoi l'appel a -http://www.phpbb-seo.com/google_sitemapindex.xml.gz affiche quelque chose ? Rien ne devrait s'afficher, on devrait juste tomber sur un transfert de fichier.

Peux tu nous dire ce qui se passe quand on appelle -http://www.phpbb-seo.com/google_sitemapindex.xml.gz ?
tu rediriges la demande vers un script php qui fait quoi exactement ?

La comme je le comprends (mal ?), tu vas chercher le fichier physique gzippé dans le cache, tu le décompresses et tu envoies ca en tant que page (et non fichier) en activant la compression gzip sur le transfert de cette page.
Si c'est ca, on utilise le cpu pour décompresser le fichier deja compressé du cache, et on réutilise le cpu pour transférer la page avec la compression gzip, alors que si lors de l'appel au fichier gz, on se contentait de faire un transfert de fichier il n'y aurait aucun travail.

quelque chose m'échappe...

Pour la liste Yahoo!, héhé, tu les veux les pages hein, bon ok, je vais de toutes façon réécrire ce sous module, donc, je mettrais une belle pagination réglable et sans ancre HTML

Moi je ne veux rien , mais je pars du principe que urllist devrait reproduire ce qui est fait pour la sitemap google, donc les memes options, et le meme niveau de détail.

Pour la notification yahoo!, je vais voir ça, ce doit pas être trop compliqué, à part peut être les histoire d'ID développeur Yahoo!.
Faudra certainement s'en faire une pour activer le module.

Ca c'est vraiment pas un souci et me semble un passage obligé. Tout le monde avait deja sa clé google (n'est ce pas ? ) il suffira d'aller s'en faire une pour yahoo.

[dcz]

Peux tu nous dire ce qui se passe quand on appelle -http://www.phpbb-seo.com/google_sitemapindex.xml.gz ?
tu rediriges la demande vers un script php qui fait quoi exactement ?

Exactement ... je fait rien.
Juste le fichier google_sitemapindex.xml.gz existe physiquement à cet endroit, aucun envois de header dynamique rien.
C'est juste un fichier que j'ai déplacé du dossier cache vers la racine pour faire un exemple. Pour le .tar.gz de sourceforge, il ne s'affiche pas car pour le coup, c'est pas vraiment un lien direct, et si ça l'étais, le navigateur comprendrait tout d'abord que le fichier est compressé, puis que c'est une archive tar, pas un fichier xml qu'il pourrait afficher

Fait toi un lien avec le fichier de l'exemple pour y faire un joli clique droit "enregistrer la cible sous" et le télécharger, je pense que ça sera plus clair.
J'évite les liens actifs ici pour ne pas créer de confusion avec le vrai plan qui lui est mis à jour

Et ne t'inquiètes pas pour le serveur, tout ce que fait le module en plus d'une lecture physique du fichier cache, c'est de maintenir la sessions et de sélectionner le bon fichier cache à envoyer tel quel, avec juste quelques header en plus (compression, type etc ..).
Quand la compression gun-zip est activé, c'est pareil, le fichier est mis en cache compressé, exactement comme l'exemple dont on parle, et il est envoyé sans décompression à l'explorateur.

Le seul cas ou le serveur pourrait être amené à décompresser un fichier serait pour permettre à un explorateur ou bot qui ne supporterait pas le standard de voir la page quand même. Et encore, uniquement si on force la compression gun-zip pour le cache, car on peut aussi bien décider de mettre une version non compressé en cache pour ce genre de cas, assez rares il est vrai.

++

[gowap]

je vais pas tarder a péter un cable, la...
je coule a pic meme quand tu me dis que tu ne fais rien de spécial et que c'est exactement le fichier du cache que tu as juste mis a la racine.

Pour le .tar.gz de sourceforge, il ne s'affiche pas car pour le coup, c'est pas vraiment un lien direct, et si ça l'étais, le navigateur comprendrait tout d'abord que le fichier est compressé, puis que c'est une archive tar, pas un fichier xml qu'il pourrait afficher

Ok, l'exemple de sourceforge est a moitié boiteux. Je pensais que ce lien la (celui obtenu en allant le plus loin dans les pages, avec spécification du serveur miroir) , une fois qu'on le balance en barre d'adresse, permettait le DL direct. C'est pas le cas, donc au grand mot les grands remedes :

Je prends un fichier gif, je le gzippe et je le balance sur mon site :
www.gravure-news.com/test.gif.gz
Tu peux essayer comme tu veux, le navigateur ne va pas afficher l'image mais va proposer de télécharger le fichier. C'est le comportement que j'ai toujours connu et que je tiens pour naturel. Ce qui arrive quand on a rien mis en place de spécial et c'est pour ca que depusi le début je m'étonne de cette url en .gz qui affiche quelque chose.

Et idem avec un fichier htm :
www.gravure-news.com/essai.htm.gz
Rien que des trucs que le navigateur est censé savoir interpréter (d'apres ce que tu me dit) apres avoir "décompressé" a la volée le gzip.

Or la, il n'y a aucune "magie", aucun affichage malgré (a cause) de la compression gzip

Je vais mal dormir cette nuit, je le sens....

[dcz]

Ah non, interdit de mal dormir pour si peut

Et avec un fichier .xml.gz ou .txt.gz ? Tu n'as rien ?
tu as essayé de DL la source de l'exemple ?

Parce qu'une image, c'est clair que c'est pas fait pour être Gun-zippé.

Aussi, il y a des différences d'en-têtes de fichiers entre les fichier Gun-zippé pour archive et ceux pour envois au navigateur.

Le module utilise la fonction gzwrite qui ne fait pas forcément exactement la même chose qu'une compression manuelle winzip ou winrar en mode Gun-zip.

Pour tout te dire, je suis loin d'être un spécialiste de la compression gun-zip, j'ai simplement pris comme base ce que nous demandais Google, un fichier sitemaps.xml ou sitemaps.xml.gz. Leur description du système n'indique pas que sitemap.php?forum est valide, même si c'est le cas. Donc, allons au plus proche de ce qui est demandé me suis-dis

J'ai donc bêtement construit des fichiers .xml.gz pour voir les headers et construire ceux du module. Je ne me suis à vrai dire pas vraiment posé la question que tu soulèves lors du développement, vu que tout se passe bien à ce niveaux.

Il faut donc croire que c'est soit une histoire d'en-tête de fichier soit une histoire de standard xml qui supporte de manière native la compression gun-zip, contrairement peut être au html qui a été définit avant la généralisation de la compression et ne l'a du coup peut être pas été autour d'une reconnaissance client de la compression gun-zip via l'extension .gz.

Un truc dans le genre je dirais.

++

[gowap]

Et avec un fichier .xml.gz ou .txt.gz ? Tu n'as rien ?

J'avais commencé par un .txt : idem , ca veut télécharger le fichier, ca n'affiche rien.

tu as essayé de DL la source de l'exemple ?

Oui, on est bien d'accord, j'obtiens un vrai fichier .gz, qui contient un xml.

Or celui ci, lors de l'appel direct a été affiché dans le navigateur.
Cette "magie" est donc forcément possible car tu as spécifié dans les entetes que l'on va faire un transfert avec compression active. A l'autre bout le navigateur du visiteur recoit le flux compressé, et le xml contenu est affiché.

Honnetement, je ne connais pas bien non plus le mecanisme de la compression de gzip des pages. Je pensais que c'était un dialogue du style "je vais t'envoyer une page html compressée"
-->envoi des données compressées (html)
-->affichage de la page dans le navigateur du client.

Je ne pensais pas que le procédé etait transparent (a partir du moment ou les entetes disent "ca va etre compressé") pour tout autre type de fichier que du html.

Pour récapituler :
tu génères la sitemap en xml.
tu enregistres ce fichier (qui fait par ex 2Mo) dans le cache en gzip --> sitemap.xml.gz (ex : 50 Ko)
ensuite quand quelqu'un appelle l'url de la sitemap, tu vérifie que le cache est a jour, si oui, tu dis explicitement dans les entetes "je vais te balancer un truc compressé en gzip" et tu envoie directement les 50 Ko de la sitemap compressée. A l'autre bout le navigateur decompresse et affiche le contenu.

[dcz]

hehe, on va finir par percer à jour ces mystères de compression.

Donc, tu as tout bon. Mais comme -http://www.phpbb-seo.com/test.txt.gz marche sur mon serveur (accès direct au fichier physique), j'en conclus que cela se joue soit au niveau de l'en-tête du fichier physique, lors de la fabrication de celui ci, soit au niveau serveur, genre, envois automatique de header, encore une fois, soit en fonction des en-têtes du fichier ou simplement pour tous (ou ceux d'une liste de types : xml, txt ...).

Dans tous les cas, c'est pas important, car le module se charge d'envoyer les header dans tous les cas. L'accès direct au fichiers en cache sera bien entendu impossible depuis le dossier cache.

La procédure complète c'est :

1) on vérifie la requête : type et compression;
2) Si le cache est activé, on vérifie si le fichier correspondant à la requête est a jour, et si c'est le cas, on envoi les bon header (compression type de données etc ...) et on envois le fichier tel quel (éventuellement compressé donc);
3) Si on en arrive là, on doit fabriquer la page, donc on le fait. Si le cache est activé on met le résultat en cache, après compression si nécessaire. Et on envois le tout, ou le fichier cache tel quel si le cache est activé.

Le fichier cache demandé est déclaré trop vieux si la date de création du fichier physique est plus vielle que xx heures, que l'on règle dans l'ACP.
Si le cache n'est pas activé, le module stocke la date de dernière génération du cache de chaque type de plan au sens large pour définir l'expiration des pages. Cela veut dire que dans ce cas, il n'y a pas d'expiration individuelle, mais générale pour chaque type de plan.

Les dates de création et d'expiration du fichier sont envoyés dans le header, ce qui devrait permettre aux bots d'ajuster parfaitement leur crawl.
Je pense que je vais aussi ajouter un tit coup de HTTP_IF_MODIFIED_SINCE et HTTP_IF_NONE_MATCH pour alléger encore la charge serveur en indiquant au explorateurs de se servir de leur version en cache pour ré-afficher la page jusqu'à expiration du délais définis dans les header.

++

[dcz]

Bon voilà, nouvelle version en ligne.

J'ai modifié la page http://www.phpbb-seo.com/rss-channels.xml.gz

Je pense que ça posera plus de problème a FF2 comme ça.

Et aussi, j'ai pas mal modifié http://www.phpbb-seo.com/urllist.txt.gz qui est maintenant capable de sortir plusieurs milliers d'url, à voir jusqu'à ou Yahoo! tiendra le choc Et aussi, pagination sujet et forum spécifiquement réglable pour la liste Yahoo! et les sitemaps Google.

J'ai également ajouté la notification Yahoo! sur les flux rss, que je vais donc de ce pas tester en vrai

Voilà, heu, quoi, d'autre, ah oui, j'ai testé plus avant la modularité, et ça marche au poil, voyez comment s'intègrent désormais les flux du forum anglophone : http://www.phpbb-seo.com/rss-board.xml.gz

On les retrouvent dans http://www.phpbb-seo.com/rss.xml.gz

Voili.

++

[dcz]

Et hop GYM sitemaps and RSS

Celui là, c'est un gros morceau, vous allez comprendre pourquoi ça a pris du temps