Suivi — Images HTTP GET 73 fois par jour depuis DLFP

#1224 Posté par  (site web personnel) . État de l’entrée : corrigée. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes : aucune
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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 14 novembre 2013 à 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 ;-)

Envoyer un commentaire

Suivre le flux des commentaires

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