Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org

Posté par  (site web personnel) . Édité par Nils Ratusznik, claudex, Benoît et Nÿco. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
57
13
juil.
2012
LinuxFr.org

Comme vous le savez certainement, LinuxFr.org vous permet d'utiliser des images externes dans les contenus et commentaires du site. Ces images sont incluses en syntaxe markdown avec ![description](URL).

Dans un souci constant d'améliorer le site, nous avons mis en place un reverse-proxy pour servir ces images. En seconde partie de la dépêche, nous détaillerons quelles sont les problématiques soulevées par les images externes et comment cet outil y répond.

N'oubliez pas que pour utiliser une image sur LinuxFr.org, vous devez vous assurer de respecter sa licence. Nous vous encourageons donc à utiliser des images sous licence libre et à citer les auteurs (c'est même obligatoire pour les licences CC-by et CC-by-sa).

Protection de la vie privée des utilisateurs de LinuxFr.org

Lorsque les images sont servies directement depuis un site externe, l'administrateur de ce site peut connaître les adresses IP de tous les utilisateurs du site qui ont affiché cette image. Depuis la mise en place d'img, seule l'adresse IP du serveur LinuxFr.org sera connue du site externe.

Sécurité

Lorsqu'un visiteur de LinuxFr.org navigue sur le site en HTTPS et qu'il accède à une page qui fait référence à une image externe servie en HTTP, le navigateur de cet utilisateur va le prévenir que le contenu de la page n'est pas sûr. Avec img, le navigateur obtiendra les images directement depuis LinuxFr.org en HTTPS ; il n'y aura donc pas d'avertissement de la part du navigateur. L'utilisateur pourra donc plus facilement détecter une véritable attaque si jamais elle survenait.

D'autre part, les images ne sont pas servies directement depuis le domaine principal mais depuis un sous-domaine pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d'attaque contre le site.

Enfin, img n'est pas un proxy ouvert sur Internet ; il n'accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 Mo.

Historique

LinuxFr.org a 14 ans d'historique et veille à préserver son contenu. Les images incluses depuis des sites externes peuvent ne plus être disponibles pour un tas de raison. Nous avons donc inclus un mécanisme de cache à img pour que nous puissions continuer à servir une image même si elle devient indisponible.

Meilleure gestion du trafic

Enfin, certaines personnes peuvent vouloir utiliser une image provenant d'un serveur à faibles ressources. Ce serveur n'est pas forcément en mesure de servir efficacement l'image en question à tous les lecteurs de LinuxFr.org. Par exemple, la bande passante montante d'une liaison ADSL serait insuffisante pour pouvoir auto-héberger une image et l'utiliser sur le site. Là encore, la mise en cache permet de garantir que le serveur ne recevra qu'un faible volume de requêtes.

Aller plus loin

  • # C'est une super nouvelle !

    Posté par  . Évalué à 6.

    Je vais pouvoir enlever plein d'images de mon serveur !

  • # Bonne idée

    Posté par  . Évalué à 7.

    Bonne idée. Un autre problème des images externes, qui n'est pas mentionné ici, est que l'image peut demander une identification HTTP. Le browser affiche alors un dialogue demandant un nom d'utilisateur et un mot de passe. Certains utilisateurs pourrait y entrer leurs informations de connexion de linuxfr, que le vilain pirate peut récupérer.

    sous-domaine pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d'attaque contre le site.

    L'utilisation d'un domaine séparé pourrait être une bonne idée, il me semble qu'en jouant avec document.domain un script sur img.linuxfr.org pourrait avoir accès à linuxfr.org (le DOM, localStorage, cookie, etc). Ça ne fonctionne que si linuxfr.org fait un document.domain=document.domain avant, mais une nouvelle fonctionnalité de linuxfr dans le futur pourrait introduire ça en oubliant que cela rend le site vulnérable.

    img.linuxfr.org pourrait également avoir accès à des cookies de linuxfr.org via document.cookie.

    Autre chose, en voulant essayer j'ai remarqué que img.linuxfr.org ne fonctionne pas lors des previews (le proxy retourne un 404).

    • [^] # Re: Bonne idée

      Posté par  (site web personnel) . Évalué à 5.

      Autre chose, en voulant essayer j'ai remarqué que img.linuxfr.org ne fonctionne pas lors des previews (le proxy retourne un 404).

      Je viens de faire le test et chez moi, ça marche. Est-ce que d'autres personnes ont rencontré le problème ? Si oui, avec quelle(s) image(s) ?

  • # Et la reconnaissance de la source ?

    Posté par  . Évalué à 7.

    Je me suis posé des questions de ce genre pour un blog perso auto-administré : est-ce que je mets un lien vers les images sur le serveur externe, ou est-ce que je les copie en local ?

    Un aspect qui n'a pas été abordé dans cette dépêche est celui de la reconnaissance de la source : est-il toujours possible pour le visiteur de LinuxFR de savoir d'où vient l'image en question ? Que pensent les distributeurs de cette image de l'idée que vous les copiiez en local au lieu de leur envoyer du trafic ? Si le contenu est soumis aux droits d'auteurs (par exemple je donne un lien vers une belle photographie ou une bande dessinée amusante), quel est le statut de cette copie ?

    Dans le cas de mon petit site, à faible traffic, j'ai jugé que ces problématiques éclipsaient largement les économie en bande passante pour le destinataire ou les problématiques de pérennité, et j'ai laissé les URLs vers des images distantes. Le bon choix pour LinuxFR est sans doute différent, mais je me demande quand même ce que vous en pensez.

    • [^] # Re: Et la reconnaissance de la source ?

      Posté par  . Évalué à 8.

      Je ne crois pas qu'un cache soit différent d'inclure l'image directement. De toute façon, si on n'a pas les droits pour afficher l'image, il faut de toute façon la supprimer, qu'elle soit en cache ou non.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # redis vs signature

    Posté par  . Évalué à 3.

    Enfin, img n'est pas un proxy ouvert sur Internet ; il n'accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 Mo.

    D'après le code, ça fonctionne de cette façon:
    - quand on poste un commentaire, ça enregistre l'url des images du commentaire dans un serveur redis
    - quand on demande une image au proxy, il vérifie que l'url existe dans redis

    Redis n'est pas un système de stockage persistent, qui est bien pour stocker des données volatiles, mais les URLs des images ne sont pas une donnée volatile.

    Est-ce que vous avez envisagé une solution à base de signature des URLs ? Si linuxfr signe les URLs des images avec HMAC par exemple, le proxy peut vérifier que l'URL a bien été générée par linuxfr, et autoriser la requête. Et du coup pas besoin de stocker une liste d'URLs.

    • [^] # Re: redis vs signature

      Posté par  . Évalué à 2.

      Il me semble que Redis permet le stockage sur disque.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: redis vs signature

        Posté par  . Évalué à 1.

        Il permet de dumper le contenu sur le disque de temps en temps, et de journaliser les commandes envoyées au serveur, mais on est loin d'une garantie de persistence/consistence des données.

        Ça n'a pas l'air très simple à mettre en place. Et si le serveur crash brutalement, des données sont perdues.

        • [^] # Re: redis vs signature

          Posté par  (site web personnel) . Évalué à 3.

          Redis est très simple à mettre en place. La consistance ne pose pas de problèmes dans notre cas. Pour la persistance, on pourrait effectivement perdre quelques données en cas de crash, mais franchement, si le serveur crash, on aura des problèmes plus graves à régler que celui-là.

          En particulier, LinuxFr.org ne tourne sur qu'un seul serveur, donc si le serveur lâche, il nous faudra quand même repartir d'une sauvegarde et accepter de perdre les données les plus récentes.

          • [^] # Re: redis vs signature

            Posté par  (site web personnel, Mastodon) . Évalué à 10.

            ça vous intéresserait d'avoir un serveur de secours, même si il date de 2008 ? j'en ai quelques uns à refourguer (gratos pour les associations). Ce sont des Dell, 1U ou 2U, de diverses puissances/capacités.
            Si oui, il vous faudrait quoi comme machine en terme de processeur, mémoire et disque ?

            • [^] # Re: redis vs signature

              Posté par  . Évalué à 3.

              Il me semble que la machine actuelle a été fournie par l'hébergeur pour des raisons de consommation électrique et donc il refuseront d'héberger du matériel qu'ils ne connaissent pas. D'ailleurs, personne ne sait à qui appartient réellement la machine aujourd'hui, si c'est un don ou un hébergement sur un serveur prêté.

              • [^] # Re: redis vs signature

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                ok, je comprend.

                il refuseront d'héberger du matériel qu'ils ne connaissent pas

                Juste une précision, au cas où certains lecteurs auraient des doutes : le matos en question n'est pas tombé d'un camion ou autre, il vient d'une ancienne boîte où j'ai bossé, et acquis légalement :-) (suite à dépôt de bilan)

        • [^] # Re: redis vs signature

          Posté par  (site web personnel) . Évalué à 1.

          Redis a un très bon système de persistance :

          • soit tu fais des dumps, qui sont "rapides" a créer et a charger, mais qui sont pas adaptes a du versioning
          • soit tu écris toutes les commandes qui vont mettre a jour ta db, comme un log. La reconstruction se fait en relançant les commandes une par une. C'est forcement un peu plus long et un peu plus volumineux, mais c'est beaucoup plus resistant aux crashs, et permet de versionner très facilement.

          Pour une base de données orientée in-memory, je trouve qu'elle se débrouille pas mal pour stocker sur le disque dur.

          • [^] # Re: redis vs signature

            Posté par  . Évalué à 2.

            soit tu écris toutes les commandes qui vont mettre a jour ta db, comme un log.

            C'est un journal en fait et c'est ce que font les systèmes de fichiers journalisés justement :)

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: redis vs signature

            Posté par  . Évalué à 1.

            Si elle se débrouillait vraiment bien, elle ferait des journaux qui commencent là où s'arrêtent les dumps.

            Parce qu'avoir un backup fait entièrement de journaux, j'imagine que ça doit être énorme.

            • [^] # Re: redis vs signature

              Posté par  (site web personnel) . Évalué à 3.

              Redis est capable de réécrire ses journaux en tâche de fond pour les compacter. Ça se fait sur une copie et, quand c'est prêt, redis intervertit les 2 journaux et roulez jeunesse !

              • [^] # Re: redis vs signature

                Posté par  . Évalué à 0.

                Oui j'ai vu ça, mais si je comprend bien ça produit un journal capable de re-créer entièrement les données (pas seulement à partir du dernier dump). Ça doit faire un journal énorme, et mettre beaucoup de temps à importer.

    • [^] # Re: redis vs signature

      Posté par  (site web personnel) . Évalué à 10.

      Redis n'est pas un système de stockage persistent

      Si, redis persiste bien ses données sur le disque dur. Il n'offre pas les mêmes garanties qu'une base de données SQL, mais ça reste suffisant pour ce cas d'usage. Au pire, on aurait régénérer les entrées de redis en reparcourant tous les contenus et commentaires.

      Est-ce que vous avez envisagé une solution à base de signature des URLs ?

      Oui, j'ai même fait plus que l'envisagée, je l'ai codée. En remontant un peu dans le temps, on peut voir https://github.com/nono/img-LinuxFr.org/blob/aa39a39d240797a44d34cf2d61b3c8984157b03b/img.go. D'un point de vue conceptuel, c'est une idée assez séduisante.

      Si linuxfr signe les URLs des images avec HMAC par exemple, le proxy peut vérifier que l'URL a bien été générée par linuxfr, et autoriser la requête. Et du coup pas besoin de stocker une liste d'URLs.

      Il y a d'autres problématiques que je n'ai pas abordées dans la dépêche, dont une importante est l'aspect modération.

      Par exemple, si une personne affiche une image nazie sur le site, on saura l'enlever des contenus et commentaires, mais l'URL de cette image sur img.linuxfr.org resterait valide. Du coup, cette même personne pourrait poster cette URL sur d'autres forums, ce qui pourrait potentiellement nous causer des ennuis avec la justice. J'ai donc implémenté un système pour bloquer les images.

      Plus vicieux, cette même personne pourrait utiliser la prévisualisation des commentaires pour récupérer cette URL sans poster le contenu. L'équipe de modération du site ne verrait alors pas passer l'image et ne pourrait donc la bloquer. Nous avons donc également une galerie des dernières images utilisées sur le site dans la partie modération.

      D'autre part, img.linuxfr.org garde en cache pour une durée assez courte les erreurs qu'il rencontre lorsqu'il va chercher une image distante (pour éviter de bourriner le serveur en question). Du coup, redis s'est trouvé être la solution la plus simple pour développer ce composant.

  • # origine

    Posté par  . Évalué à 4. Dernière modification le 13 juillet 2012 à 13:27.

    avec ce système, il y a un moyen de savoir d'ou vient l'image originale ?

    j'ai peut-être pas tout compris :)

    • [^] # Re: origine

      Posté par  . Évalué à 5.

      Oui, en fait l'url des images est //img.linuxfr.org/img/hex(url d'origine).

      Exemple:

      test

      A comme URL:

      http://img.linuxfr.org/img/68747470733a2f2f613234382e652e616b616d61692e6e65742f6173736574732e6769746875622e636f6d2f696d616765732f6d6f64756c65732f61626f75745f706167652f6f63746f6361742e706e673f31333135393238343536

      En décodant la partie après /img/ (via http://www.string-functions.com/hex-string.aspx par exemple) on trouve:

      https://a248.e.akamai.net/assets.github.com/images/modules/about_page/octocat.png?1315928456

      • [^] # Re: origine

        Posté par  . Évalué à 3.

        whaou, ca pourrait être intéressant d'ajouter l'url source soit à travers une balise A soit dans le title

        • [^] # Re: origine

          Posté par  . Évalué à 1.

          Je pense que le problème dans ce cas est que tu ne servirais plus l'image mais un bout de html, ce qui est une autre problématique (comment tu l'inclus dans ta page, avec javascript ?).

          Le système en hex suffisamment simple, en plus il assure l'unicité. Éventuellement il pourrait ajouter un img.linuxfr.org/xxxx/origin qui te donnerais l'origine de l'url, mais bon hein, faut avoir du temps !

          Bravo en tout cas, la fluidité des arguments sur la pertinence de la solution montre que c'est bien pensé. Beau boulot.

          • [^] # Re: origine

            Posté par  . Évalué à 6.

            je me suis mal exprimé, ou alors, j'ai mal compris ton commentaire.

            Ce que je voudrais, c'est :
            - texte en markdown avec le lien vers l'image http://totoz.eu/gif/jeans.gif

            qui serait transformé en :
            < a href="https://totoz.eu/gif/jeans.gif" >< img src="img.linuxfr.orgl2345654534345453>< /a>

            ainsi, on aurait le bénéfice du cache tout en gardant la provenance et de façon simple.

            Ca éviterait que certains viennent dire "vous m'avez volez mes images". L'argument pourra être de dire, non, c'est du cache.

      • [^] # Re: origine

        Posté par  . Évalué à 2.

        Petite remarque : pourquoi utiliser une fonction de codage si gourmande ?

        Déjà en base64 on diminue pas mal la longueur (et ça me semble compatible avec le format des URL) :
        aHR0cHM6Ly9hMjQ4LmUuYWthbWFpLm5ldC9hc3NldHMuZ2l0aHViLmNvbS9pbWFnZXMvbW9kdWxlcy9hYm91dF9wYWdlL29jdG9jYXQucG5nPzEzMTU5Mjg0NTYK

        Donc 125 octets au lieu de 184 (pour 92 octets au départ). Après on peut aussi utiliser des fonctions de hachage plus performantes.

        Le problème avec l'hexa c'est qu'on peut vite faire exploser la longueur de l'URL (genre pour mettre à mal IE, je n'ai qu'à poser une image dont l'URL fait plus de 1000 et quelques caractères) : http://www.dubourg.name/s9y/archives/88-Longueur-maximale-des-URL.html

        • [^] # Re: origine

          Posté par  (site web personnel) . Évalué à 7.

          Déjà en base64 on diminue pas mal la longueur (et ça me semble compatible avec le format des URL)

          Un des caractères utilisés en base64 est le slash (/). Si plusieurs slashs se retrouvent collés dans l'URL, certains navigateurs les compactent en un seul slash.

          Le problème avec l'hexa c'est qu'on peut vite faire exploser la longueur de l'URL

          On pouvait déjà le faire avant. Les gens qui postent des images le font pour qu'elles soient vues, donc je doute qu'ils aillent chercher des URL si compliquées. Au pire, c'est juste que l'image ne va pas s'afficher, rien de bien méchant.

          • [^] # Re: origine

            Posté par  . Évalué à 3.

            Un des caractères utilisés en base64 est le slash (/). Si plusieurs slashs se retrouvent collés dans l'URL, certains navigateurs les compactent en un seul slash.

            Dans ce cas tu fais ta propre fonction de transformation comme base64 mais sans prendre le / dans les caractères utilisés :). Ça doit être parce que je commence à être un dinosaure qui essaye d'écrire des code IHM ne bouffant par inutilement de la bande passante que ça me choque d'utiliser une méthode de transformation aussi gourmande.

            Après, quitte à faire une meilleure transformation, autant utiliser une fonction de hachage performante comme sur les sites de réduction d'URL.

            Enfin je dis ça, ce n'est pas moi qui vais faire le développement d'un telle idée … c'est déjà un super boulot que tu as fait (une fois de plus). Ça va enfin me permettre de voir les jolies nimages qui sont souvent bloquées par le proxy très strict de ma boite.

            • [^] # Re: origine

              Posté par  . Évalué à 3.

              Après, quitte à faire une meilleure transformation, autant utiliser une fonction de hachage performante comme sur les sites de réduction d'URL.

              L'avantage de hex et de base64 c'est qu'elles sont bijectives. Les raccourcisseurs d'URL te file juste un identifiant encodé pour ne pas être séquentiel si je ne m'abuse.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: origine

                Posté par  . Évalué à 5.

                Comme tu travailles en ruby tu peux utiliser la méthode urlsafe_encode64() http://ruby-doc.org/stdlib-1.9.3/libdoc/base64/rdoc/Base64.html :

                require 'base64'
puts Base64.urlsafe_encode64(ARGV[0])
# equivalent à 
puts [ARGV[0]].pack('m0').tr('+/', '-_');

                Cette discussion m'a permis de découvrir la page http://en.wikipedia.org/wiki/Base64 qui est très intéressante (surtout la partie "Variants summary table")

                L'avantage de hex et de base64 c'est qu'elles sont bijectives. Les raccourcisseurs d'URL te file juste un identifiant encodé pour ne pas être séquentiel si je ne m'abuse.

                Après il faut se poser la question de savoir à quoi sert la bijection dans ce genre de cas (je pense qu'il n'y aura pas plus de monde à vouloir décoder les liens en hexa/base64 que de personne à essayer de dépasser la longueur maximale autorisée dans les navigateurs/serveurs ;) ? Le seul risque serait une collision sur 2 images différentes mais avec un md5 ou un sha-1 il faut vraiment le vouloir (ou pas avoir de chance du tout).

                Sinon dernière bidouille pour gagner quelques octets : compresser en gzip l'URL avant de la mettre en base64 :

                use Compress::Zlib;
use MIME::Base64;
print encode_base64(compress($ARGV[0]))."\n"

                • [^] # Re: origine

                  Posté par  . Évalué à 2.

                  Comme tu travailles en ruby

                  Je ne suis pas Bruno Michel !

                  Après il faut se poser la question de savoir à quoi sert la bijection dans ce genre de cas (je pense qu'il n'y aura pas plus de monde à vouloir décoder les liens en hexa/base64 que de personne à essayer de dépasser la longueur maximale autorisée dans les navigateurs/serveurs ;) ?

                  C'est retirer une fonctionnalité sympa. C'est bien de pouvoir retrouver la source d'une image.

                  Le seul risque serait une collision sur 2 images différentes mais avec un md5 ou un sha-1 il faut vraiment le vouloir (ou pas avoir de chance du tout).

                  À utiliser sha1 ou md5, il suffit de saler et de vérifier la non-existence de la clef avant inversion et changer le sel si besoin.

                  Sinon dernière bidouille pour gagner quelques octets

                  Si le nombre d'octets et si important qu'on met autant de barrières au reverse de l'url, il s'agit plus de générer un identifiant que de hasher cryptographiquement une donnée :

                  http://dev.petitchevalroux.net/php/generer-identifiant-alphanumerique-php.281.html

                  Ça seras je pense toujours plus performant sur le serveur tout en permettant de garder un contrôle de la taille des url.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: origine

                    Posté par  . Évalué à 1.

                    À utiliser sha1 ou md5, il suffit de saler et de vérifier la non-existence de la clef avant inversion et changer le sel si besoin.

                    Sauf que c'est plus que probablement la même image dans ce cas là. C'est même plutôt bien si on veut blacklister une image: ça évite d'utiliser quatre urls équivalentes pour contourner la modération (avec/sans www, avec un / au bout, etc). Et c'est plus court, donc le html est plus lisible.

                    • [^] # Re: origine

                      Posté par  . Évalué à 2.

                      J'avais mal compris tu parlais d'un md5 de l'image je croyais que tu parlais de l'URL (comme c'est le cas pour hex).

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: origine

                    Posté par  . Évalué à 0.

                    Je ne suis pas Bruno Michel !

                    /o\ ben oui mais quelle idée aussi s'appeler Barret Michel et de répondre à un de mes commentaires qui faisait suite à une réponse Bruno Michel … en plus juste avant le week-end !!!

                    C'est retirer une fonctionnalité sympa. C'est bien de pouvoir retrouver la source d'une image.

                    Oui mais comme indiqué dans les commentaires ça serait encore plus sympa d'être rediriger sur l'URL d'origine automatiquement (genre en ajoutant /source à la fin de l'URL de reverse proxy).

                    À utiliser sha1 ou md5, il suffit de saler et de vérifier la non-existence de la clef avant inversion et changer le sel si besoin.

                    On est d'accord (mais ça rajoute x caractères de salage ;)

                    Si le nombre d'octets et si important qu'on met autant de barrières au reverse de l'url, il s'agit plus de générer un identifiant que de hasher cryptographiquement une donnée

                    Je suis d'accord avec toi, mais je ne faisais que donner un exemple qui répond à la contrainte de la bijection complète mais en "optimisée". En plus question performance c'est pas un gzip sur 1000 caractères qui va faire une grosse différence.

                    • [^] # Re: origine

                      Posté par  . Évalué à 2.

                      À utiliser sha1 ou md5, il suffit de saler et de vérifier la non-existence de la clef avant inversion et changer le sel si besoin.

                      On est d'accord (mais ça rajoute x caractères de salage ;)

                      Ça n'a pas d'influence sur la taille de l'URL générée.

                      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: origine

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                Sinon il existe aussi d'autres encodages, pas forcément plus économes, mais plus rigolos ;)

                Genre Bubble Babble : http://bohwaz.net/p/PHP-5-implementation-of-Bubble-Babble-encoder-decoder

                « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: origine

              Posté par  . Évalué à 2.

              http://thedailywtf.com/Articles/That-Wouldve-Been-an-Option-Too.aspx

              Depending on the time of day, the French go either way.

          • [^] # Re: origine

            Posté par  . Évalué à 6.

            petites questions comme ça…

            • quid de Gravatar ? C'est la seule chose qui ne va pas rester en cache du coup, mais c'est sans doute fait exprès alors…
            • Si une image change sur le serveur ensuite, est-ce qu'elle sera re-cachée, ou bien c'est la version au moment de la rédaction qui sera privilégiée ?

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: origine

              Posté par  (site web personnel) . Évalué à 4.

              quid de Gravatar ? C'est la seule chose qui ne va pas rester en cache du coup, mais c'est sans doute fait exprès alors…

              Je vais peut-être utiliser img pour les avatars. C'est juste pour le moment, je n'ai pas tellement réfléchi à comment le faire, si c'est vraiment pertinent out non, etc. Mais j'aime bien l'idée :)

              Si une image change sur le serveur ensuite, est-ce qu'elle sera re-cachée, ou bien c'est la version au moment de la rédaction qui sera privilégiée ?

              Actuellement, c'est la version au moment du premier affichage qui est privilégiée, mais ça devrait évoluer rapidement. Dès que je trouve un peu de temps, je vais faire en sorte que l'on aille chercher les mises à jour de l'image.

              • [^] # Re: origine

                Posté par  . Évalué à 2.

                Pour gravatar ce serait dommage de perdre l'usage du cache du navigateur (nouvelle URL) l'image étant potentiellement utilisé pour d'autre sites/réseau sociaux.

                • [^] # Re: origine

                  Posté par  . Évalué à 2.

                  D'ailleurs il peut être intéressant de passer des informations de cache en HTTP par exemple (cache de 60 jours):

                  Cache-Control: max-age=5184000,max-stale

                  ou Cache-Control: max-age=5184000,public

                • [^] # Re: origine

                  Posté par  . Évalué à 4.

                  Je ne vois pas pourquoi: pour l'objectif de protection de la liste des adresse IP, gravatar est un morceau de choix: chez gravatar ils doivent avoir dans leurs log de quoi reconstituer les habitudes de la terre entière (mails, adresses IP, sites webs consultés).

                  Si j’envisageais de devenir dictateur du monde, je m'interesserait à gravatar avant la base de données de la Hadopi…

                • [^] # Re: origine

                  Posté par  (site web personnel) . Évalué à 4.

                  On en risque pas de le perdre vu qu'il n'est déjà pas utilisé.

                  Pour profiter du cache du navigateur, il faudrait que les URL utilisées soient exactement les mêmes sur LinuxFr.org que sur d'autres sites. Or, nous passons dans les URL gravatar, l'adresse de l'avatar par défaut. Du coup, les URL utilisées pour charger les gravatars sont différentes sur les autres sites et on ne profite pas du cache du navigateur quand on arrive sur LinuxFr.org depuis un autre site avec des gravatars.

        • [^] # Re: origine

          Posté par  . Évalué à 4.

          Donc 125 octets au lieu de 184 (pour 92 octets au départ). Après on peut aussi utiliser des fonctions de hachage plus performantes.

          Sur des volumes normaux gratter 59 octets d'URL quand tu vas chercher une image, qui va faire entre 8k si c'est un 64x64 et quelques centaines de ko, ca change pas la face du monde.

  • # Requêtes simultanées

    Posté par  . Évalué à 3.

    Je ne peux plus éditer mon commentaire précédent, j'ajoute mes question dans un nouveau commentaire:

    Le code du serveur a l'air super simple (et ça donne envie de faire du Go :) ). Est-ce que Go et/ou pat gère les requêtes concurrences ? Est-ce que si un serveur distant met un certain temps à répondre à une requête ça peut bloquer les autres requêtes ?

    • [^] # Re: Requêtes simultanées

      Posté par  (site web personnel) . Évalué à 8.

      Pas de soucis de ce coté là, Go gère ça très bien. Le package net/http crée une nouvelle goroutine pour chaque connexion HTTP entrante.

      Une goroutine est un contexte d'exécution très léger et Go multiplexe ensuite les goroutines sur des threads.

  • # Un essaie

    Posté par  . Évalué à 3. Dernière modification le 13 juillet 2012 à 13:45.

    Nimage de panda

    Édition : pourquoi ça marche pas ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Un essaie

      Posté par  . Évalué à 2. Dernière modification le 13 juillet 2012 à 13:54.

      ben ça marche, qu'est-ce que tu dis ?
      https:// img.linuxfr.org/img
      /687474703a2f2f75706c6f61642e77696b696d656469612e6f72672f
      77696b6970656469612f636f6d6d6f6e732f7468756d622f382f38322
      f4769616e745f50616e64615f5461695f5368616e2e4a50472f383030
      70782d4769616e745f50616e64615f5461695f5368616e2e4a5047

      • [^] # Re: Un essaie

        Posté par  . Évalué à 2.

        Ok sur mon firefox j'ai du aller voir l'url que tu donne pour valider le certificat pour img.linuxfr.org et ensuite j'ai pu voir l'image.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Un essaie

          Posté par  (site web personnel) . Évalué à 5.

          Pour les personnes qui utilisent la version HTTPS du site, nous recommandons d'ajouter le certificat de cacert pour éviter d'avoir à accepter manuellement les certificats de LinuxFr.org. Cf l'aide.

          • [^] # Re: Un essaie

            Posté par  . Évalué à 3.

            Tiens je ne l'avais jamais fait. C'est corrigé. :)

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Un essaie

            Posté par  (site web personnel) . Évalué à 6.

            Il y a un lien (LE lien, même) non fonctionnel dans cette rubrique, qui ne semble pas modifiable par la vulgus moulum : 

            [...] vous devez en premier lieu ajouter le [certificat racine](http://www.cacert.org/index.php?id=3) au trousseau [...]

            Qui devrait s'afficher ainsi : certificat racine, mais apparaît non parsé dans cette page.

          • [^] # Re: Un essaie

            Posté par  . Évalué à 2. Dernière modification le 13 juillet 2012 à 18:53.

            oui, sauf si on n'a pas envie de faire confiance à cacert…

            edit: oui bon ok j'ai été lire vos motivations, elles me paraissent effectivement fondées: cacert est pas pire que les autres, peut-être même mieux…

  • # Très similaire à Thumbor

    Posté par  . Évalué à 3. Dernière modification le 13 juillet 2012 à 14:49.

    Thumbor est un projet en python de http://globo.com qui est complètement fait pour ça.
    Il permet en plus d'appliquer des filtre sur les images pour toute sorte d'effets.

    Il permet aussi d'authentifier le générateur de l'url par une clé HASH dans l'url ainsi un site externe ne pourra pas phagocyter le service pour ses propres images.

    • [^] # Re: Très similaire à Thumbor

      Posté par  (site web personnel) . Évalué à 3.

      Effectivement, je ne connaissais pas Thumbor, mais ça a l'air d'être très sympa et ça aurait pu nous servir (il aurait juste fallu le modifier un peu pour les questions de modération).

  • # Pour les images qui sont actualisées à intervalles réguliers

    Posté par  . Évalué à 5.

    Que va-t-il se passer pour les images qui sont générés toutes les x minutes pour suivre l'évolution d'un débit ou autre, par exemple celles de la dépêche https://linuxfr.org/news/6-juin-2012-world-ipv6-launch ?

  • # pourquoi de l'hexa et pas du base64 ?

    Posté par  . Évalué à 1.

    base64 ça faisait des urls trop courtes ? ;-)

Suivre le flux des commentaires

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