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 Bruno Michel (site web personnel) . En réponse à l’entrée du suivi HTTP GET 73 fois par jour depuis DLFP. Évalué à 3 (+0/-0). Dernière modification le 14 novembre 2013 à 10:50.
Pour tester, tu lances img, puis tu fais ça dans un terminal :
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 ;-)