Problème d’entêtes HTTP qui disparaissent ? Jetez donc un oeil à votre firewall

Publié le 10 Mar 09 à 07:17 | Catégorie : Développement Web | 5 commentaires

Pour la petite histoire, j’étais en train de revoir la semaine dernière la configuration d’un site de commerce électronique (basé sur la plateforme de vente Magento) pour un client et plus particulièrement de mettre en place les bonnes pratiques pour optimiser ses performances. En l’occurrence, il s’agissait de vérifier que la compression gzip de certains types de fichiers (comme par exemple les feuilles de style) était bien effective. Le meilleur moyen pour vérifier ce genre de choses est tout simplement d’utiliser YSlow, l’extension pour Firefox développée par les équipes de Yahoo!.

Malheureusement, YSlow m’indiquait à chaque test que ces fichiers étaient retournés par le serveur Apache sans avoir été compressé. J’ai donc consulté plus en détail les entêtes HTTP renvoyées par ce serveur grâce à Live HTTP Headers - un autre plugin indispensable pour développer une application web - sans toutefois trouver l’entête concernée. En effet, si tout fonctionne correctement, le serveur va ajouter l’entête suivante à la réponse :

1

Content-Encoding: gzip

Bien sûr, il faut que le navigateur ait précisé auparavant dans sa requête qu’il accepte ce type de compression :

1

Accept-Encoding: gzip,deflate

Dans mon cas, non seulement l’entête Accept-Encoding avait été supprimé, mais en plus l’entête Content-Length qui spécifie la taille de la réponse indiquait bien la taille du fichier non compressé. Hors côté serveur, les fichiers de log d’Apache montraient que le fichier avait bien été retourné compressé. Et cette page de test remontait les mêmes résultats. Bref, c’était à ne plus rien y comprendre. Pas de la magie noire, mais presque…

Heureusement, au fil de mes recherches sur Internet, je suis tombé un peu par hasard sur cet article qui explique que certains logiciels pare-feu (comme on dit en français) suppriment ou réécrivent parfois ces entêtes. J’ai donc sorti l’artillerie lourde : Ethereal (qui s’appelle maintenant Wireshark) pour inspecter les paquets échangés au niveau de mon propre réseau. Et en effet, en désactivant le firewall, tout est revenu à la normale.

Pour information, j’utilise Outpost Firewall et même en suspendant la protection, ce dernier restait quand même actif et supprimait cette entête. Il a fallu que je quitte complètement cette application pour la voir enfin réapparaître. Outpost Firewall récupérait donc bien une réponse du serveur qui avait été compressé, la décompressait et supprimait l’entête Content-Encoding avant de la faire parvenir au navigateur.

A lire également

Les visiteurs qui ont vu cette page ont consulté ensuite :

A savoir

Si vous le souhaitez, vous pouvez être prévenu de la parution de nouveaux articles en vous abonnant par RSS ou par email.

5 commentaires à propos de “Problème d’entêtes HTTP qui disparaissent ? Jetez donc un oeil à votre firewall” :

  1. Piouf, en voyant le titre de l’article je pensais qu’il s’agissait de firewall côté serveur. Moi qui viens de revoir totalement mon iptables, je me voyais déjà tout refaire.

    Me voilà rassurer. D’un côté, on peut comprendre pourquoi l’antivirus ou le firewall en viennent à décompresser les flux afin des les vérifier, de l’autre il pourrait fournir l’original au navigateur c’est un peu absurde comme fonctionnement.

    J’ai eu une histoire similaire sur un e-commerce avec des client qui se plaignait de ne pas voir les photo produits. Il était tous équipé de Norton je ne sais plus quoi qui avait un antipopup de fournis qui supprimait bêtement toutes images de 500 x 500px de lapage web.

    Seza le 10 March 2009 à 19:45 (#1)

  2. Dans un même ordre d’idée, je n’arrivais plus depuis quelques jours à voir les photos sur le site de l’OpenCoffee Club Sophia avec Firefox. Hors tous les autres navigateurs fonctionnaient parfaitement et affichaient les images en provenance des serveurs de Flickr. En investiguant, c’est Firefox qui avait tout simplement décidé de bannir certaines adresses de Flickr. Le problème est semble-t-il assez courant, puisque Flickr a mis au point une page de test avec toutes les explications nécessaires. A bon entendeur ;).

    Stéphane le 10 March 2009 à 20:44 (#2)

  3. Intéressant !

    Hier dans le même genre, sur un de mes sites, un voile blanc semi transparent s’est installé par dessus le site rendant tout clique impossible. Très étrange, je n’ai pas eu le temps de savoir si Firefox, l’antivirus ou google-analytics (pourquoi pas, c’est pas impossible) était en cause que le problème a disparu. Je soupsonne Firefox néanmoins car c’était le seul navigateur à présenté le problème.

    Seza le 10 March 2009 à 21:10 (#3)

  4. Bel exploit ;o)
    On a tendance à oublier tous les maillons de la chaine qui sont ( plus ou moins ) nécessaires pour faire fonctionner un service aujourd’hui.
    A une époque ou je développais en desktop, je fuyais comme la peste les composants tiers qui, à mon sens, fragilisaient l’applicatif.
    Aujourd’hui avec les technos web on est dépendant de beaucoup de “middleware” qui peuvent mettre en danger les développements.
    Dans cette catégorie, je déteste les caches : cache local, cache applicatif, cache de la base de données etc.
    Il faut se transformer en détective privé pour trouver qui est le coupable en cas de dysfonctionnement !

    Domi le 12 March 2009 à 10:11 (#4)

  5. T’es quand même assez tenace Stéphane !
    En tout cas, bien joué pour ton analyse : c’est un problème récurrent dans le cas de firewall applicatifs un peu “trop sécurisé”.

    Romain le 13 March 2009 à 11:39 (#5)

Ajouter un commentaire

Les informations obligatoires sont indiquées par une étoile rouge *.


dis donc, c'est la folie ces services de rédaction en ce moment. Il y en a un nouveau tous les jours :).

Articles Récents

Les derniers articles publiés

A Propos

Je m’appelle Stéphane Thomas et je suis Ingénieur Senior expert dans le développement d'applications web complexes. Etant également un peu Entrepreneur, j'ai tenté l'aventure de la création d'un nouveau service Internet appelé Loomiz. Je suis maintenant le cofondateur d'Hitomi Studio, un studio de développement spécialisé dans la réalisation de sites ecommerce haut de gamme pour de jolies marques.

Lire la suite…