Pourquoi ?
En théorie, c’est simple (dans les temps anciens, sous windows XP, tout marchait je crois...) En pratique, ce fut compliqué...
Error: "Connect Error" (-4) after 2 retries at link localhost
)Attention, c’est un gros hack bourrin mais ça marche...
Le problème sur localhost peut être résolu en changeant par 127.0.0.1, mais certains liens sont convertis en localhost sur le mirroir static (???) et des boucles de récursivité se créent. Pas idéal.
Begin gros hack
cf fichier de configuration avec mes options ci-joint. À charger via Preference -> Load options
« Ah ouais, mais avec tes options on télécharge tout internet ! »
Exact.
Pour éviter ça, j’ai installé Comodo Internet Security http://www.comodo.com/products/free... et j’ai réglé le parefeu pour autoriser l’accès en local et interdire internet.
Faut se faire des règles dans le style (dans l’ordre)
Sur comodo, ça donne quelque chose dans ce genre :
End gros hack
Mangez, c’est chaud !
Il existe un problème actuellement pas très résolu... aucun des profils de WinHTTrack ne récupère 100% des liens internes du site, sauf "Go everywhere on the web".
Sauf que WinHTTrack s’obstine à convertir en relatif les liens externes (sauf si on les met en exclusion par -*google.*), ce qui n’est évidemment pas gérable manuellement.
L’option ne pas convertir les liens en relatif plante complètement le site...
Je crois que le plus qu’à faire un plus gros hack encore plus sale :
La pseudo-racine générée par WinHTTrack contient des répertoires du style
projetice.crdp.ac-lyon.fr
www.comodo.com
www.legifrance.gouv.fr
www.oxygenepc.com
www.spip.net
...
Il suffirait de faire un script qui ouvre tous les html générés, et utilise cette information pour les repatcher correctement... ouais... ça sent le truc de geek pourri qui prend 1h toute l’après-midi.
PPS : C’est fait, voir HTTrack link patch
PPPS : Actuellement, le patch fonctionne, mais reste imparfait : les liens externes contenant ? ou php sont modifiés avec une séquence aléatoire par httrack, que je ne vois pas comment corriger autrement qu’à la main (en les donnant à une version pas encore publiée de mon patcher, ce qui explique que ce site fonctionne quand même), ou en réécrivant un téléchargeur de site (faisable, mais on perd un peu l’intérêt d’htttrack). Il faudrait que je contacte les auteurs d’httrack pour résoudre le problème ...
Par ailleurs, le patch ne fonctionne pas encore sur les fichier php (pour une simple question d’extension qui sera résolue dès la modification de la librairie ListDir.au3). Sans conséquence décelable actuellement (car les rss sont à moitié désactivés).
PS4 : Le 02/08/2015. Un nouveau problème est survenu, rien d’évident n’a été changé au système mais ça ne marche plus... IPV6 s’est réactivé suscitant les problèmes antérieurs avec httrack qui n’est pas compatible avec cette technologie. Un test par ping ::1 objective que IPV6 est activé. La méthode pour désactiver IPV6 ne marche plus (https://support.microsoft.com/en-us/kb/929852), quelque chose remet DisabledComponents à 0 au redémarrage (ou à la fermeture). Le fixit ne marche pas plus qu’en manuel en mettant DisabledComponents à (0x) "ff". Une manoeuvre ésotérique a marché : fermer la session, remettre à ff avec une autre session admin. La fermer. Revenir à la session normale. Httrack marche et DisabledComponents est toujours à ff, et IPV6 marche selon ping ::1 (la causalité est jugée aléatoire).
Ce problème est non documenté sur google. Il s’agit sans doute soit d’une mise à jour de windows qui force IPV6, soit d’un logiciel tiers ayant les droits admin (antivirus ? firewall ? service inconnu ?).
La conclusion est que maintenir un système de "production" sur un PC d’usage normal est trop risqué. Prochaine étape (quand le problème reviendra...) : migration à l’identique de ce qui marchait dans une machine virtuelle coupée du réseau.