Petite modification au niveau du comportement du shaarli. Depuis un moment ma version intègre le header Last-Modified avec la date de changement du fichier datastore.php (ou sont sauvegardés les liens).
J'ajoute quelques lignes pour que cela soit utile côté client, en interrogeant le header de requête If-Modified-Since de mon côté (serveur donc). S'il existe, alors on le compare à la valeur de Last-Modified et selon que le contenu a été modifié ou non, le status sera adapté :
- 304 Not Modified
- 200 Ok (thus modified)
Cela ne devrait pas bloquer le fonctionnement habituel (sinon c'est une régression / c'est pas voulu).
En gros pour obtenir le Last-Modified :
$ curl https://dukeart.netlib.re/links/?do=rss -I 2>/dev/null | grep -ie last-modified
last-modified: Sun, 17 Jan 2021 17:13:30 GMTEt pour consulter le flux et le télécharger uniquement lorsqu'il est modifié (on place la date reçue précédemment dans le header) :
$ curl https://dukeart.netlib.re/links/?do=rss -H "If-Modified-Since: Sun, 17 Jan 2021 17:13:30 GMT"La requête renvoie un 200 (et le contenu) si la date de modification du contenu (Last-Modified) est plus grande que la date que vous fournissez. Si le client intègre la mécanique pour chaque flux, cela permet de consulter très régulièrement sans faire de transfert inutile.
Au niveau du code ajouté dans le shaarli, c'est pas méchant :
<?php
$headers = getallheaders();
$last_modified = date("D, d M Y H:i:s", filectime("data/datastore.php")) . " GMT";
if ( array_key_exists("If-Modified-Since", $headers) ) {
$tx = new DateTime($headers["If-Modified-Since"]);
$tm = new Datetime( $last_modified );
if ( $tm <= $tx ) {
header("HTTP/1.1 304 Not Modified");
exit;
}
}
?>Je pense que ça reste convenable mais je suis ouvert aux critiques ^^ (même sur le principe de base d'ailleurs).
La 0.12 est déjà disponible et j'y passerai rapidement (merci à la communauté).
Le lien est changé en /links (pas original mais justement :p). L'ancien lien est redirigé.
Je reste sobre dans les modifs pour l'instant, j'ai quand même dupliqué un bloc pour avoir un lien de retour vers la racine du site (en haut à droite) (tout en conservant le home du shaarli à gauche) :
<li class="pure-menu-item" id="shaarli-menu-desktop-home">
<a href="https://dukeart.netlib.re" class="pure-menu-link"
id="home-button" title="{'Home'|t}">~
</a>
</li>Autre chose lié au header Last-Modified : il est généré à la date en cours avec comme commentaire que c'est pour "prévenir un système de cache client ou proxy".
Je dois rater un truc parce que c'est bien l'intérêt de ce header de servir de marqueur sur la date de mise à jour du contenu, non ?
Je suis tenté de mettre le ctime du fichier datastore.php mais pourquoi c'est pas déjà le cas ?
Merci, t'assure !
Arf, seulement le premier fichier peut être importé sans erreur et ça date de ... dukeart.free.fr (qui existe toujours au passage). Mais dans mon cas, je m'auto-héberge et tout le tuttim donc j'assume mes erreurs. C'est déjà un bonus qui fait plaisir !
Mais je retrouve des liens intéressants, attention chérie ça va parser.
Si tu peux me dire quelle était l'erreur de mon flux stp, histoire de corriger si j'ai fait une bêtise... d'ailleurs il est temps de mettre à jour !
Ma modeste contribution à la connexion inter-shaarli.
Elle marchouille (/o\ pétée de partout) encore. Je ne suis pas sûr de son utilité mais avec un système de cache (interne mais pourquoi pas aussi via le navigo, en PWA) et une reprise du code php, ça pourrait être sympa, non ?
Un grand merci à tous \o/
PS (un détail) : Je me demande pourquoi le bouton Home est paramétrable si, en fait, les boutons '<Nom du shaarli>' et 'Home' pointent sur le même lien ?
J'ai mis ma racine en dur du coup :)
Très bonne idée ! J'aimerai qu'on puisse avoir ce(s) mini-réseaux de shaarlis. On se brancherai de proche en proche avec possibilité de filtrer sur ce qui est agrégé. Je pense aux flux principaux, on pourrai chercher dans ces ensembles, est-ce que ce serait efficace ? J'en sais rien. Mais ça pourrait être très ciblé pour des sujets spécifiques.