Google SDCH et HTTP

On vous a dit de compresser vos échanges HTTP avec gzip ou deflate, des les identifier avec des ETag, mais pouvons nous faire mieux ? C’est la question abordée par certaines équipes de Google (slides disponibles) en juin dernier aux conférences Velocity 2008. Ils partent du principe qu’une page web est composée de plusieurs éléments, dont certains sont communs à plusieurs pages et ne nécessitent pas d’être renvoyés.

Google propose donc un codage supplémentaire pour HTTP qui s’appelle SDCH, et qui peut s’ajouter avant gzip ou deflate. Le serveur découpe sa page en paquets, qui peuvent chacun avoir des métadonnées et une expiration explicite. Le tout est stocké dans un dictionnaire du côté du navigateur, un peu comme les cookies actuellement. Quand le navigateur demande une page il envoie les identifiants de paquet qu’il connaît déjà, le serveur peut donc se contenter de compléter ce qui manque. On a donc le même fonctionnement que les Etag du point de vue de la négociation.

Les entêtes HTTP en jeu sont Avail-Dictionnary (l’équivalent de Etag pour SDCH) et X-SDHC (pour déclarer la version et l’implémentation de SDCH utilisée) du côté du navigateur, et X-SDCH-Dictionary du côté du serveur.

Reste que cela implique que la réponse du serveur soit codée suivant une forme bien particulière, non compatible avec les anciens clients HTTP. Google a donc prévu une auto-négociation et la réutilisation de l’entête Accept-Encoding. Grâce à cela, les navigateurs qui le peuvent auront un contenu SDCH puis compressé par gzip, les autres se contenteront du gzip.

Si vous voyez passer un Accept-Encoding: sdch, gzip c’est que votre navigateur supporte ce codage. Si en plus vous voyez une réponse Content-Encoding: sdch, gzip c’est que le serveur a bien compris que vous supportiez SDCH et va utiliser ce codage.

Je n’ai vu aucun mouvement ni aucune volonté de mouvement de la part de Mozilla, en fait depuis la communication de Google l’idée n’a pas l’air d’avoir fait recette où que ce soit. Seul un groupe de discussion, quasi vide, a fait suite à la communication de juin 2008.

Chrome a un premier support de SDCH (non activé par défaut pour la version publique actuelle) mais ça ne changera pas la face du monde. Le point intéressant est toutefois que SDCH est automatiquement intégré à Microsoft Internet Explorer si la Google toolbar est installée. La page d’aide de Google indique comment désactiver tout ça.

Si l’idée peut être intéressante, je suis un peu étonné que Google tente de l’imposer de lui-même sans avoir le support d’au moins un intervenant (Mozilla, Opera, Apple, Microsoft) ou une publication normative officielle de type RFC. La seule chose qui sauve cet unilatéralisme est la présence d’une version dans l’auto-négociation (donc on pourra gérer d’éventuelles évolutions dans les spécifications si jamais tout le monde se met autour de la table pour en rediscuter).

Publié par edaspet

Plus d'informations sur mon profil en ligne

5 réponses sur « Google SDCH et HTTP »

  1. En fait si 😉
    Les frames ça aurait été N requêtes indépendantes, ça aurait été encore pire du point de vue des performances pour les visites sans cache (qui représentent toujours au moins 20%), et vu le cout d’une iframe (environ 100ms même si elle est vide) ça aurait été un problème même pour ceux qui ont un cache initialisé.

  2. Bon alors pour ceux qui nous lisent encore : Éric et moi avons discuté, et en fait nous ne parlions pas de la même chose.

    Moi je parlais d’indexation brute (au sens parcours par le robot et lecture du contenu), là où Éric parlait de l’indexation ‘relative’ de la frame par rapport à son conteneur.

    (c’est un peu compliqué et il est trop tôt dans la matinée pour que je m’étende plus avant). 😉

Les commentaires sont fermés.