L'image compare la diffusion de contenu avec et sans RSS. Sans RSS, les utilisateurs doivent vérifier manuellement les mises à jour des sites. Avec le RSS, le nouveau contenu est automatiquement envoyé aux utilisateurs via les lecteurs RSS ou apparaît dans les résultats de recherche via les agrégateurs de contenu.

Flux RSS : pourquoi ils restent indispensables pour suivre le web sans algorithmes

par · Lecture: 6 minutes

Je suis tombé, il y a déjà longtemps, sur un schéma publié par Search Engine Land qui résumait très bien le principe des flux RSS. L’image avait quelque chose de presque militant : elle montrait comment un simple flux pouvait relier un site, ses lecteurs, ses agrégateurs, ses outils de veille et même les moteurs de recherche.

À l’époque, RSS représentait surtout un confort de lecture. Aujourd’hui, il représente quelque chose de plus rare : un moyen de suivre le web sans dépendre d’un algorithme.

Et franchement, ce n’est pas rien.

Qu’est-ce qu’un flux RSS ?

RSS signifie Really Simple Syndication. C’est un format XML qui permet à un site de publier automatiquement ses nouveaux contenus dans un fichier structuré. Ce fichier contient généralement le titre de l’article, son lien, sa date de publication, un extrait, parfois l’image principale, et d’autres métadonnées utiles.

En clair, le site publie. Le flux se met à jour. Le lecteur RSS récupère l’information.

Pas besoin d’ouvrir vingt onglets. Pas besoin de rafraîchir une page d’accueil. Pas besoin d’attendre qu’un réseau social daigne afficher l’article dans un fil d’actualité.

RSS fait le travail proprement, en silence.

Le principe : centraliser l’information

Le système RSS est ingénieux parce qu’il évite de multiplier les marque-pages et les visites manuelles.

Au lieu d’ouvrir chaque site un par un, on ajoute leurs flux RSS dans un lecteur comme Feedly, Inoreader, NewsBlur, Netvibes ou FreshRSS. Ensuite, tous les nouveaux articles arrivent dans une seule interface.

C’est le même principe que le webmail pour les emails : on ne va pas frapper à la porte de chaque serveur. On centralise tout dans un outil unique, accessible depuis un ordinateur, une tablette ou un téléphone.

Lire la suite

Rihanna en fedora noir et veste à rayures tient une mitraillette vintage, sûre d'elle dans "Shy Ronnie 2" avec The Lonely Island. À côté d'elle, Shy Ronnie aux cheveux roux, coiffée d'un béret et vêtue d'un pull à rayures, réagit nerveusement près des stores de la fenêtre.

The Lonely Island et Rihanna dans Shy Ronnie 2 : humour, rap et braquage raté

par · Lecture: 5 minutes

Il y a des clips qui cherchent à impressionner. Et puis il y a Shy Ronnie 2: Ronnie & Clyde, qui préfère faire exploser le casse du siècle à cause d’un rappeur trop timide pour parler correctement.

Sorti comme SNL Digital Short le 30 octobre 2010, ce sketch musical de The Lonely Island met en scène Rihanna et Andy Samberg dans une parodie de braquage façon Bonnie and Clyde. Sauf qu’ici, Clyde est Rihanna, sûre d’elle, dangereuse et parfaitement dans son rôle. Ronnie, lui, est censé l’aider. En théorie seulement.

Shy Ronnie 2: Ronnie & Clyde (feat. Rihanna)

Lire la suite

Solution pour l'erreur 400 (bad request) lors d'un renouvellement de certificat Let's Encrypt sous Plesk photo

Plesk : corriger l’erreur 400 Let’s Encrypt au renouvellement SSL

par · Lecture: 7 minutes

Lors du renouvellement d’un certificat Let’s Encrypt sous Plesk, il peut arriver que la validation échoue avec une erreur 400 Bad Request. Le message ressemble souvent à ceci :

Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected error:

Failed authorization procedure.

www.example.com (http-01):
urn:ietf:params:acme:error:unauthorized ::
The client lacks sufficient authorization ::
Invalid response from
http://www.example.com/.well-known/acme-challenge/2VQAX5eA_dSyl1RB5MjfcHr9YinF8T7nw3Z6OxU5Zu4:

"<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>"Langage du code : PHP (php)

En clair, Let’s Encrypt essaye de lire un fichier de validation dans /.well-known/acme-challenge/, mais le serveur ne renvoie pas le token attendu. À la place, il renvoie une page d’erreur 400 Bad Request.

Ce n’est donc pas un problème “SSL” au sens strict. C’est d’abord un problème d’accès HTTP au fichier de challenge ACME.

Comprendre le challenge HTTP-01 de Let’s Encrypt

Lorsque Plesk demande ou renouvelle un certificat Let’s Encrypt avec le challenge HTTP-01, l’autorité de certification vérifie que le serveur répond bien sur le domaine demandé.

Pour cela, elle tente d’accéder à une URL du type :

http://example.com/.well-known/acme-challenge/TOKENLangage du code : JavaScript (javascript)

Le fichier doit être accessible publiquement sur le port 80. Let’s Encrypt précise que le challenge HTTP-01 nécessite le trafic entrant sur le port 80, et que les IP de validation ne sont pas publiées car elles peuvent changer.

Let’s Encrypt suit les redirections HTTP, jusqu’à 10 redirections, mais uniquement vers http ou https sur les ports 80 ou 443. En revanche, si une redirection crée une boucle, pointe vers un hôte incorrect, casse le Host header, passe par un proxy mal configuré, ou renvoie une page 400, la validation échoue.

Dans Plesk, cette validation est généralement gérée par l’extension Let’s Encrypt / SSL It!. Plesk peut renouveler automatiquement les certificats, mais seulement si le domaine reste accessible de l’extérieur pendant la validation.

Lire la suite

Suivant →