“The underlying connection was closed: The server committed an HTTP protocol violation.
Error reading URL: The underlying connection was closed: The server committed an HTTP protocol violation.
Please try to validate this feed. If this feed validates as correct RSS, you can send an error report. “
If you use an RSS feeds agregator like SharpReader, SauceReader or FeedReader, this error might sound familiar to you. Here is an explanation on how to prevent this…
The issue
The HTTP header keys for example shoud specifically not include any spaces in their names. However, some web servers do not fully respect standards they’re meant to.
Applications running on the Dotnet framework and making heavy use of http requests usually use the “httpWebRequest” class, which encapsulates everything a web oriented developer could dream of. With all the recently issues related to security, the “httpWebRequest” class provides a self protection mechanism preventing it to accept HTTP answers which not fully qualify to the specifications.
The common case is having a space in the ‘content-length’ header key. The server actually returns a “content length” key, which, assuming no spaces are allowed, is considered as an attack vector (HTTP response split attack), thus, triggering a “HTTP protocol violation error” exception.
The workaround
It is possible since the 1.1 SP 1 DotNet version (UPDATE: see comments for instructions prior to version 1.1, credits to Krys Oye) to disable this error check. (Un)Fortunately, DotNet allows you to modify some parameters directly through a simple text configuration file, thus not requiring the user to have some strong developer skills.
I tested this on SharpReader and it immediatly unlocked all the ‘red’ feeds I had.
1. Create a file and name it like ‘yourapplication.extension.config‘. If for example you’re using SharpReader, then create a file named ‘SharpReader.exe.config‘.
2. Open this file with a notepad or any text-based editor and paste the following text in it:
<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
</configuration>
*: Be carefull: if you already see that file in the folder, edit it, and only insert the missing sections in it. Do not try to reproduce a second ‘configuration’ area for example as it will invalidate that configuration file.
3. Save it, then restart your application. That should work now.
Thanks to…
This workaround was found on Gille’s weblog, thanks to him: I can keep my favourite SharpReader 
Les flux RSS (comprendre Really Simple Syndication) avaient originalement pour objectif de favoriser l’échange des flux d’informations grâce à une spécification basée sur la technologie XML. C’est d’ailleurs un peu pour cela XML a été conçu, non ?
Seulement, voilà, les sites proposant du contenu ‘externe’ ne sont pas si nombreux qu’on pourrait le croire. Principaux concernés, les portails et autres sites chargés d’agréger du contenu ne forment pas le ‘gros’ d’Internet et bien que le gain puisse être perceptible en termes d’interopérabilité, ce n’est pas à raison de cinquante actualités transmises par flux RSS, par jour, qu’un portail va se retrouver sur ses genoux.
Qui utilise RSS ?
La faille avec RSS réside dans sa facilité d’utilisation et d’intégration. Quelques compétences de développeur en herbe, deux heures de lecture attentive sur la spécification technique de la norme et le tour est joué: vous avez un flux RSS sur votre site perso.
Tout cela serait encore acceptable si la déferlante des blogs (comprendre: sites persos possédant une trame chronologique d’actualités) n’avait pas démarré il y a environ deux ans. Gratuits, commerciaux, hébergés, mutualisés, simples, compliqués, via le mobile, avec ou sans album photo, communautaires ou open source sur son domaine perso: il y en a pour tous et pour tous les goûts. N’importe qui peut se mettre à blogger (comprendre: poster des articles sur son blog) après cinq minutes chrono, recherche d’un fournisseur gratuit et configuration de départ compris.
L’on a déjà vu ce cercle vicieux quelque part… Ah oui! Le web: un projet à la base destiné à des applications militaires, puis pédagogiques devenu une plate-forme à la fois de loisirs mais également de commerce sur laquelle s’échange plusieurs milliards d’octets de données par seconde. Comment font les militaires et les universités ? Ils réfléchissent sur des projets comme ‘Internet 2' ou encore ‘The Grid’, en cachette.
Le problème avec tous ces blogs c’est que le concept fonctionne si bien que chacun se retrouve rapidement avec une liste de plusieurs dizaines d’adresses, surveillées, à l’affût de la moindre mise à jour sur le site du copain de la copine, du geek mentor ou encore du type qu’on ne connaît pas mais qui satisfait, sans le savoir, toutes nos pulsions refoulées de voyeurisme, en racontant les moments les plus intimes de sa vie!
C’est là que RSS devient utile. Et pas du tout pour faciliter l’échange de contenu entre différentes applications. Le flux RSS est si facilement ‘extrait’ et analysé que n’importe quel blog dispose de son petit bouton ‘RSS’ , ‘RSS2', ou encore ‘ATOM’.
Apparaissent alors les agrégateurs de flux RSS. Des outils gratuits pour la plupart ou payants (les opportunistes, nous en aurons toujours) tels que SharpReader, NewsGator, Radio Userland, FeedDemon, Sauce Reader, Straw, Bloglines ou encore NetNewsWire pour les fanas de la pomme; il y a l’embarras du choix.
On mélange le tout, on y ajoute un souci d’organisation et voilà que naissent des communautés entières d’utilisateurs d’agrégateurs de flux RSS, eux-mêmes chargés de surveiller entre 10 et 250 flux chacun. Soucieux d’être les premiers à réagir ou être au courant de ce qu’il se passe, certains n’hésitent pas à paramétrer leurs agrégateur pour lancer leur ronde de surveillance toutes les deux ou cinq minutes.
Le goulot d’étranglement
Nous avons donc d’un côté des utilisateurs soucieux de ne pas perdre leur temps en visitant des sites n’ayant pas été mis à jour et utilisant un agrégateur de flux pour faire le sale boulot à leur place et de l’autre, des sites presque forcés de fournir ce service sous peine de voir leur audience chuter.
A cela s’ajoute la portée psychologique des agrégateurs de flux: un bloggeur regarde les statistiques de visite de son site et les nombres grandissent de manière exponentielle! Il se croit soudainement intéressant et se met donc à écrire plus encore. En écrivant plus, il augmente presque toujours sa notoriété, qu’elle soit bonne ou mauvaise et donc le nombre d’ “abonnés” à son flux RSS.
Cela ne saute pas aux yeux au premier abord mais RSS est un retour en arrière: on revient au traditionnel ‘PULL’ (demander l’information) au lieu du très convoité ‘PUSH’ (l’information qui vous intéresse vient à vous). C’est sous nos yeux: utiliser RSS de manière efficace exige que l’on aille demander l’état du flux directement à sa source et tant qu’il n’y a rien de nouveau, cela fait un trafic d’informations inutile.
Par analogie, imaginez que vous allez vous coucher, vous devez vous lever à 6 heures 30 du matin et que vous regardiez l’heure toutes les minutes pour voir s’il n’est pas déjà 6 heures 30. Vous l’avez deviné: nous utilisons un réveil. RSS est ce réveil, mais paradoxalement, RSS a besoin lui-même d’un réveil!
Un réveil ?
Ce qui n’est pas intéressant avec le réveil c’est que quelque part dans la chaîne, il y a toujours quelqu’un ou quelque chose qui doit aller vérifier régulièrement si une condition n’est pas remplie. Votre réveil fait également ce travail: lors de tout changement d’heure, il compare les heures des alarmes planifiées et s’il y a correspondance, déclenche l’alerte.
Ce problème a été résolu avec la presse: les abonnements! L’abonnement est la plus singulière démonstration du remplacement d’un ‘PULL’ (l’intéressé va voir, quand il y pense, dans le magasin de tabacs, si son magazine préféré est sorti) et un ‘PUSH’ (l’abonné reçoit automatiquement son magazine et l’éditeur s’assure une vente inconditionnelle de ses numéros durant un an par la même occasion).
Une solution (conclusion?)
Le concept d’abonnement aux flux commence à se faire connaître. Certains agrégateurs de flux proposent un service d’abonnement permettant ainsi de ‘centraliser’ les requêtes sur une seule machine: un agrégateur est désigné comme “maître” et les autres clients n’effectuent leurs requêtes que sur cet agrégateur.
Bref, j’imagine un serveur sur lequel sont abonnés plusieurs dizaines (centaines, milliers) de clients. Ce serveur centralise tous les flux surveillés par ses clients et effectue lui-même les différentes requêtes sur chaque flux RSS.
Lorsqu’un client se connecte à Internet, il utilise un agrégateur légèrement modifié: il ne demande pas, il écoute. L’agrégateur annonce sa présence au serveur principal (en jargon technique: lui communique son adresse IP et son port d’écoute) et se place alors en position d’écoute.
Lorsque le serveur détecte une mise à jour dans l’un des flux, il consulte la liste de tous ses clients abonnés à ce flux, et déclare l’association client-flux comme ‘modifiée’. Un autre processus fonctionnant en parallèle est chargé de surveiller continuellement cette liste d’associations ‘client-flux modifié’ et la liste ‘clients connectés’. Tous les clients connectés reçoivent dès lors le contenu mis à jour du flux correspondant.
Qu’y gagnerait t’on ?
1) La consommation de bande passante serait extrêmement réduite et ceci à tous les niveaux de la topologie du réseau. Ce genre d’outil se destinerait principalement à des fournisseurs d’accès.
2) Les utilisateurs reçoivent VRAIMENT l’information en temps réel dans la mesure où il ne s’agit plus de jongler avec l’intervalle chaque requête.
3) Seules les mises à jours sont échangées sur le réseau, il n’est pas nécessaire de faire des demandes lorsque aucune modification n’a été effectuée.
4) Avec la centralisation de la liste de flux, un fournisseur d’accès pourrait par exemple créer différents groupes ou communautés virtuelles autour de flux basés sur un même centre d’intérêt.
5) Dans le cadre de réseaux d’entreprise, les débits seraient fortement réduits tout en permettant une gestion centralisée de la sécurité et de la qualité des flux choisis par les collaborateurs.
6) Je dois sûrement en oublier…
Bref, j’ajoute que si cette idée n’existe pas encore, maintenant c’est chose faite. Je n’ai pas le temps de développer cela gratuitement mais si quelqu’un est prêt à y investir un salaire, je veux bien