HTTP est devenu au cours des dernières années le protocole à tout faire. Au départ prévu pour servir de l'information structurée par lien hypertexte, il est aujourd'hui utilisé pour tout et n'importe quoi. Cette évolution ne va pas sans poser de problèmes. C'est pourquoi sous l'égide de l'IETF un groupe de travail httpbis s'est mis en place.

Une nouvelle mouture du protocole tarte à la crèmeHTTP est donc en route. Faisons un petit tour de son histoire et des projets en cours, avant d'écouter ce qu'à a nous en dire Willy Tarreau qui s'est particulièrement investi dans le groupe de travail httpbis.

NdM : Merci à Nÿco, Florent Zara, patrick_g, Raoul Volfoni, baud123, warwick, Nils Ratusznik, NeoX, zebra3 et Benoît pour leur contributions à cette dépêche.

ExaProxy est un nouveau proxy HTTP s'ajoutant à une longue liste de logiciels libres (SQUID, haproxy, varnish, tinyproxy…). Il se place dans le secteur de niche des proxy filtrants principalement desservis commercialement par des entreprises comme BlueCoat ou Fortinet.

Dans ce domaine, SQUID est la plus connue des solutions libre grâce à une interface simple permettant l’écriture rapide de modules de filtrage qui reçoivent l'IP de hôte connecté avec la requête faite. SQUID supporte aussi ICAP/eCAP pour ceux qui veulent modifier la requête et la réponse du serveur.

Cependant, afin d'avoir un filtrage différent par IP d'origine, il est impossible d'utiliser SQUID avec un load balancer de niveau 7, comme haproxy, qui change l'IP d'origine. Seules les solutions de haute disponibilités ré-écrivant l'adresse MAC de destination (comme ipvsadmin) sont adaptées. De plus, SQUID ne présente pas les requêtes de type CONNECT.

ExaProxy est donc un forward proxy permettant de filtrer ou router le trafic transitant dans un cluster de manière très souple, et permet l'utilisation du header X-Forwaded-For quand l'IP de l’hôte est masquée. Une autre utilisation peut être comme passerelle entre machines IPv4 et IPv6.

Le fonctionnement du serveur peut-être observé via une interface web sur le port local 8080.

Quand des chercheurs en informatique font de la théorie, certains écoutent, comme les développeurs de Perl. D'autres dorment au fond de la classe : cette fois, le bonnet d'âne est pour PHP, Python, V8 (JavaScript par Google, qui sert par exemple dans node.js), Ruby (sauf CRuby), de nombreux serveurs d'applications en Java, mais aussi ASP.NET. Ils ont dû se réveiller brutalement mercredi, lors d'une présentation d'Alexander Klink et Julian Wälde au Chaos Communication Congress montrant comment saturer très simplement un serveur grâce à une attaque basée sur la complexité algorithmique.

HTTP Strict Transport Security, ou HSTS, est un brouillon de norme Internet qui propose une méthode pour augmenter la sécurité des sites web en apportant une solution à une faille courante située entre la chaise et le clavier.

Il s'agit pour les sites web sécurisés d'indiquer au navigateur qu'il doit systématiquement forcer l'accès en HTTPS.

Nginx est à la fois un serveur HTTP et un proxy inverse pour HTTP et IMAP / POP3.
Поехали, la version 1.0.0 est sortie hier.

Développé sous licence BSD, Nginx sert fidèlement de nombreux sites Web, dont LinuxFr.org, et leur apporte performances, fiabilité et configurabilité. Des études indiquent qu’il servirait entre 6,5 % et 7 % du Web mondial (derrière Apache et IIS, mais devant Google, Lighttpd et Cherokee).

Cette version 1.0.0 arrive après 9 ans de développements soutenus et montre, s’il en est besoin, la stabilité du projet. Je vous encourage à l’essayer.

La nouvelle version de LinuxFr.org est en ligne depuis quelques jours. Vous nous remontez régulièrement des bugs et des propositions d'améliorations dans le suivi. Je vous encourage à continuer et à commenter / voter sur les entrées qui vous intéressent.

Voici quelques entrées sur lesquelles j'aimerais particulièrement avoir vos retours :

• Pour ou contre le respect de la syntaxe Markdown pour les retours à la ligne ?
• Quels services devrait-on prendre en charge pour les avatars ? Certains d'entre vous utilisent-ils pavatar ?
• Que pensez-vous des polices utilisées ?

Je pense que vous êtes également intéressés par l'architecture logicielle de cette nouvelle version. Vous pourrez donc trouver quelques explications à son sujet en seconde partie et n'hésitez pas à poser des questions dans les commentaires.

Ashd est un serveur HTTP conçu selon la philosophie Unix : simplicité et modularité. Ashd (A Sane HTTP Daemon) est écrit en langage C, sous licence GPLv3 et vient d'annoncer sa sortie officielle en version 0.1. Il se compose d'un ensemble de programmes simples ayant chacun un rôle bien déterminé. Ashd a été pensé selon 4 piliers fondateurs :

• Une conception saine : en application directe de la philosophie UNIX, ashd est découpé en plusieurs programmes qui font une seule chose, mais le font bien
  
• La sécurité : comme chaque processus ne fait qu'une seule chose, il est facile de restreindre ses droits au minimum dont il a vraiment besoin
  
• Une configuration simple et sensée : chaque programme ayant une responsabilité limitée, il est facile de le configurer (les options en ligne de commande suffisent généralement)
  
• La persistance : les processus sont persistants et peuvent ainsi garder des données de session en mémoire ou conserver des connexions vers des backends.
  

Ashd est composé des modules suivants :

• htparser, pour écouter les connexions TCP et parler en HTTP avec les clients
  
• dirplex, pour servir des fichiers depuis un répertoire (la réponse est déléguée à sendfile)
  
• patplex, pour les règles de gestion virtuelle
  
• sendfile, pour répondre aux clients avec un fichier et gérer les entêtes HTTP associés (content-type, last-modified, etc.)
  
• callcgi, pour appeler des scripts CGI
  
• userplex, pour servir les répertoires des utilisateurs à la /~user/ (ce programme est lancé avec l'utilisateur en question, ce qui évite les problèmes que l'on peut avoir avec apache qui tourne en www-data)...
  

Unicorn est un serveur applicatif HTTP en Ruby comparable à Mongrel ou à Thin, sous licence GPLv2. Il est utilisé notamment par Twitter et Github et vient d'atteindre la version 1.0.

Unicorn est compatible avec Rack, une interface entre les serveurs applicatifs et les frameworks. Il peut ainsi être utilisé pour servir des applications Ruby, dont celles écrites en Ruby on Rails. Il tourne avec Ruby 1.8, Ruby 1.9 et bientôt Rubinius. Rappelons que Rubinius est une implémentation alternative de Ruby dont la version 1.0 est sortie récemment.

Unicorn s'appuie au maximum sur les noyaux Unix pour éviter de réinventer la roue. Par exemple, la répartition des requêtes entre les différents processus se fait grâce à une socket partagée. Il est également possible de mettre à jour Unicorn, l'application ou l'interpréteur Ruby sans perdre la moindre connexion.

De même, Unicorn est optimisé pour servir des clients rapides. Il est donc très souvent utilisé derrière un reverse-proxy, qui pourra bufferiser les requêtes des clients lents.

A l'inverse, utiliser Unicorn pour des connexions longues comme du Comet (Comet désigne un ensemble de techniques où un serveur maintient des connexions HTTP ouvertes pour pouvoir pousser des contenus vers les clients) ou des websockets serait très inefficace, je vous conseille pour cela de regarder Rainbows : c'est un projet inspiré d'Unicorn qui vise justement à répondre à cette problématique particulère.