Suivi - Images HTTP GET 73 fois par jour depuis DLFP

#1224 Posté par (page perso) . État de l'entrée : corrigée Licence CC by-sa
Tags : aucun
3
12
nov.
2013

Ce 11 novembre j'ai posté un journal qui contient une image : https://linuxfr.org/users/krunch/journaux/dlfp-journalyser-2-1-rester-au-top

Depuis, 88.191.250.176 a récupéré l'image 147 fois. Je veux bien que DLFP mette l'image en cache et vérifie périodiquement qu'elle n'a pas changée mais la récupérer en entier 73 fois par jour me semble un petit peu excessif et contre-productif.

À vrai dire je ne suis pas sûr de comprendre pourquoi DLFP vérifie que l'image ne change pas. Les journaux et commentaires ne sont pas librement éditables après publication donc il ne me semble pas logique de le permettre pour les images qui en font partie.

S'il y a une raison légitime pour cette vérification, il serait sans doute judicieux d'utiliser les en-têtes adéquats pour que le serveur en amont puisse répondre avec une 304 au lieu de retélécharger toute l'image à chaque fois.

  • # consensus & patch

    Posté par (page perso) . Évalué à 3 (+0/-0).

    Si on peut avoir un consensus sur le comportement à adopter et que le code à modifier est disponible (ce qui ne semble pas vraiment le cas), je veux bien tenter d'écrire un patch.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: consensus & patch

      Posté par (page perso) . Évalué à 4 (+0/-0).

      Pour ce qui est du comportement, c'est volontaire que le code aille rechercher régulièrement si l'image a été modifiée. Cela sert, par exemple, pour les images dynamiques comme celles qui affichent un compteur de dons ou le nombre de jours restants avant un événement. Par contre, c'est vrai que la gestion des headers de cache pourrait être améliorée.

      Le code se trouve sur https://github.com/nono/img-LinuxFr.org (c'est du go).

      • [^] # Re: consensus & patch

        Posté par (page perso) . Évalué à 5 (+0/-0).

        Pour le reste du comportement (et pour avoir les références sous le coude), HTTP/1.1 en-têtes If-Modified-Since (14.25) et If-None-Match (14.26) http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

      • [^] # Re: consensus & patch

        Posté par (page perso) . Évalué à 4 (+0/-0).

        OK, je penserai à mettre un Goatse à retardement sur ma prochaine dépêche.

        Je vais tenter de voir à écrire un patch dans les jours/semaines qui viennent. Ça me fait une excuse de plus pour me mettre au Go.

        Merci.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: consensus & patch

          Posté par (page perso) . Évalué à 2 (+0/-0).

          Bon, j'ai un brouillon de patch qui Devrait Marcher. Me reste plus qu'à trouver comment tester.

          Par contre j'ai bien l'impression que ce serveur de cache est sujet à des conditions de course. Il est sans doute possible de se retrouver avec un Content-Type qui ne correspond pas au fichier ou avec un fichier tronqué ou mélangeant des bouts de deux fichiers.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

          • [^] # Re: consensus & patch

            Posté par (page perso) . Évalué à 3 (+0/-0). Dernière modification le 14/11/13 à 10:50.

            Bon, j'ai un brouillon de patch qui Devrait Marcher. Me reste plus qu'à trouver comment tester.

            Pour tester, tu lances img, puis tu fais ça dans un terminal :

            # On stocke dans redis l'URL pour l'autoriser
            $ redis-cli hsetnx 'img/http://linuxfr.org/images/logos/logo-linuxfr-automne.png' created_at 1              
            
            # On encode en hexadécimal l'URL
            $ irb
            > 'http://linuxfr.org/images/logos/logo-linuxfr-automne.png'.unpack('H*')
              => ["687474703a2f2f6c696e757866722e6f72672f696d616765732f6c6f676f732f6c6f676f2d6c696e757866722d6175746f6d6e652e706e67"]
            
            # Puis, on fait une requête dessus avec curl ou wget
            $ wget http://127.0.0.1:8000/img/687474703a2f2f6c696e757866722e6f72672f696d616765732f6c6f676f732f6c6f676f2d6c696e757866722d6175746f6d6e652e706e67/logo.png

            Par contre j'ai bien l'impression que ce serveur de cache est sujet à des conditions de course.

            Oui, je m'étais déjà dit ça. Si je me souviens bien, le problème était l'absence de synchronisation entre le moment où l'on écrit le fichier sur le disque et les appels à redis. On pourrait effectivement se retrouver avec un mauvais Content-Type dans ce cas.

            En pratique, ça m'avait l'air hautement improbable que ça se produise et, au pire, pas très compliqué à nettoyer à la main. Donc, j'ai du me dire que je verrais ça un autre jour ;-)

            • [^] # Re: consensus & patch

              Posté par (page perso) . Évalué à 2 (+0/-0).

              C'est surtout le "installer les 42 dépendances et lancer les deux daemons" qui me manquait. J'ai un peu réfléchi à comment rendre ce bazard testable proprement mais ça sera pour une autre fois.

              J'ai une patch queue de quatre patches et j'ai testé que ça fait ce que ça doit. Sans « vrai » tests c'est dur d'étre raisonnablement sûr que j'ai rien cassé mais ça a l'air d'aller.

              J'ai pas de compte github donc http://fruli.krunch.be/~krunch/src/dlfp/suivi1224/

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: consensus & patch

              Posté par (page perso) . Évalué à 2 (+0/-0).

              Et tant que je suis à rapporter les bugs que personne va jamais remarquer, le Last-Modified renvoyé par img dépend des locales alors que ça devrait toujours être GMT. Voilà un patch qui s'applique par dessus les autres : http://fruli.krunch.be/~krunch/src/dlfp/img-Return-Last-Modified-time-conform-to-RFC2616.patch

              pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

              • [^] # Re: consensus & patch

                Posté par (page perso) . Évalué à 3 (+0/-0).

                J'ai appliqué tous les patchs et c'est en prod. Merci !

                • [^] # Re: consensus & patch

                  Posté par (page perso) . Évalué à 2 (+0/-0).

                  Arg, ça ne résoud pas le problème pour les images qui étaient déjà en cache avant l'application du patch puisque saveImageInCache() retourne avant de stocker l'ETag si la checksum correspond.

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.