Absolument : nous avons fait l’impasse sur Expires puisque trop « primaire » dans le contexte dynamique.
Je ne suis évidemment pas du tout contre l’idée de fournir un exemple de configuration Expires, au contraire. Mais je ne sais pas sous quelle forme cela serait le plus judicieux (cas de serveurs Nginx, IIS, etc. ou d’apache sans gestion des .htaccess ou aux .htaccess aux « pouvoirs » limités). Et comme je le disais, et j’ai vu qu’il y avait déjà un ticket à ce sujet (http://dev.dotclear.org/2.0/ticket/1035), le point délicat reste le mécanisme interne de détermination de la fraicheur des contenus, qui n’est pas des plus « smart ». :-) De : dev-boun...@list.dotclear.org [mailto:dev-boun...@list.dotclear.org] De la part de Julien Wajsberg Envoyé : lundi 29 juillet 2013 11:44 À : dev@list.dotclear.org Objet : Re: [Dotclear Dev] Dotclear et le Cache HTTP (Was: plugin postsStats) je viens de vérifier, et les headers If-None-Match et If-Modified-Since sont en effet gérés, chouette, my bad, mea culpa, tout ça :) en revanche, on gère pas du tout les Expires, ça pourrait valoir le coup d'avoir ça dans le .htaccess par défaut pour les ressources statiques ? 2013/7/29 Pep <p...@callmepep.org> Le cache HTTP est géré, et plutôt pas trop mal géré pour du dynamique. Ensuite, pour aller plus loin, il y a les plugins de cache cités par Franck qui, même sans être la panacée, s'avèrent être rudement efficaces une fois bien configurés (et bons également pour les ressources serveur). Il y a une faiblesse dans le design de DC pour gérer facilement et finement un cache statique. Ça demanderait un gros travail de fond qui sera sans doute fait un jour. Mais pour le cache HTTP, lis bien le code et tu verras que sa gestion est plus que correcte. Le 29 juil. 2013 à 00:31, Julien Wajsberg <fel...@gmail.com> a écrit : 2013/7/29 Franck Paul <carnet.franck.p...@gmail.com> Il existe deux plugins de cache dispo sur DA http://plugins.dotaddict.org/dc2/details/staticCache http://plugins.dotaddict.org/dc2/details/memCache en fait, ça configure pas du tout les headers HTTP nécessaires. Tout ce que ça fait (mais c'est déjà pas mal) c'est cacher statiquement les résultats des scripts PHP, et les rebalancer au client quand il le redemande, ce qui économise de la ressource serveur. Les headers HTTP de cache dont je parle, ça peut provoquer 2 choses: * le navigateur ne va même pas aller chercher une mise à jour s'il pense que la ressource est encore à jour * s'il pense qu'elle doit être vérifiée (on dit "revalidée"), il va faire une requête conditionnelle, et le serveur web va vérifier si la ressource est à jour (il va juste renvoyer un 304 sans aucune autre information, notamment aucun payload, ce qui dit au navigateur de prendre la ressource dans son cache), ou bien pas à jour (dans ce cas il renvoie un 200 avec toute la page, comme si la requête n'était pas conditionnelle) ça économise encore plus de ressource serveur, mais aussi de la ressource réseau, et en plus ça va plus vite pour le client. évidemment, dans le cas d'une page dynamique générée par PHP, c'est au logiciel de gérer tout ça, et c'est loin d'être trivial, ya un peu de boulot :) -- Dev mailing list - Dev@list.dotclear.org - http://ml.dotclear.org/listinfo/dev -- Dev mailing list - Dev@list.dotclear.org - http://ml.dotclear.org/listinfo/dev
-- Dev mailing list - Dev@list.dotclear.org - http://ml.dotclear.org/listinfo/dev
