Désolé pour l'aspect "bourrin" de ma réponse (visiblement ça te choque) mais il reste encore le problème des domaines qui disparaissent et sont tout de suite cybersquattés par des "wildcards" publicitaires (peu importe ce qu'on met dans l'URL, ça affiche la page de pub, il n'y a pas de 404 retourné). Là ce n'est pas une question d'hébergeur car l'hébergeur a changé. Malheureusement il est difficile de savoir quand un domaine a dispru et a été remplacé à moins de vérifier les infos WHOIS (qui cependant indiquent le plus souvent uniquement le registrar mais souvent pas l'identité du propriétaire; cependant les squatteurs publicitaires de domaines tombés ont l'habitude de mettre le nom de leur contact ou au moins un contact pour les mails, ne serait-ce que parce que ces domaines sont souvent à revendre) L'ennui c'est que les infos WHOIS ne sont pas dans un format normalisé: chaque registry a son format avec des différences notables. L'ICANN a bien essayé de normaliser ça mais avec les nomlbreux anciens TLDs il n'a pas été possible de leur faire changer leurs méthodes. Connaitre l'identité d'un site est délicate, même avec des certificats PKI pour HTTPS (qui est malheureusement encore trop peu déployé, les registrars facturant les certificats encore trop cher pour nombre de sites).
Mais bon là on parle de l'IGN, et je ne vois pas pourquoi il ne ferait pas les choses correctement sur son propre domaine qui malgré tout n'a pas changé, le problème étant ici la mauvaise gestion des contenus sur leurs serveurs pour garder des URL pertinentes, et qui ne savent pas gérer ça sur plusieurs CMS qui changent d'un projet à l'autre. L'IGN n'est pas seule à faire ça, regardez ce que fait Microsoft sur ses propres sites, y compris de référence, dont les URL changent tous les 2-3 ans à chaque édition d'une version d'Office ou Windows ou d'autres projets ou SDK, et qui pourtant utilise des URLs plus ou moins anonymisées avec des identifiants uniques (Microsoft est le premier à utiliser les UUIDs partout dans ses APIs, mais pas sur son propre site pour indexer les contenus correctement!) qui devraient normalement pouvoir survivre à des changements ou ajouts de contenus ou de formats: cherchez une doc dans un SDK, 2 ans après le lien est mort et même la fonction de recherche ne retourne plus les bonnes versions et la version décrite ne fonctionne pas de la façon documentée, ou bien le langage a carrément changé. Ici on est dans un cas similaire: changement de méthodes, remplacement complet d'un site par un autre sans préserver la moindre compatibilité ou au moins fournir des identifiants de rapprochements ou une page utilitaire affichant d'autres liens pertinents (même sans beaucoup de détails, au moins une liste. Ca doit se produire quand l'IGN a changé de prestataire et s'est fait fournir un autre système incompatible avec le précédent et du jour au lendemain décide d'arrêter un système pour brancher l'autre sans prévoir aucune migration autre que depuis une seule page d'accueil. Le 20 janvier 2017 à 21:57, <osm.sanspourr...@spamgourmet.com> a écrit : > Merci j'avais bêtement recopié la réponse à une question qui portait > pourtant spécifiquement sur les headers. Professionnellement j'utilise bien > HEAD quand j'en ai besoin, je ne pensais pas tomber sur une réponse aussi > bourrine non relevée par un autre internaute. > > Vu ta remarque, il vaut mieux sans doute supprimer le -L. Normalement dans > le cas que tu cites on devrait avoir un 301 ou 302 sauf si l'hébergeur ne > joue pas le jeu. Non testé. > > Jean-Yvon > > Le 20/01/2017 à 21:02, Philippe Verdy - verd...@wanadoo.fr a écrit : > > Méthode couteuse: les requêtes ici sont des GET mais ça récupère tout > (même si tu filtres ensuite par un head -n 1). Un HEAD serait plus > approprié (pour ne récupérer d'abord que les entêtes et pas les pages > entières) : c'est suffisant pour obtenir un statut 404. > > Note: certains sites retournent une page 200 même quand l'URL est invalide > (un "wildcard" récupère ce qui n'est pas trouvé et affiche une autre page): > pratique courante sur les sites commerciaux qui veulent afficher mlalgré > tout leur portail et font à l aplace des recherches plus ou moins liées aux > termes demandés dans la requête, ce qui n'est pas toujours en grand rapport > avec ce qu'on cherchait. Idem pour les sites hébergeurs de blogues ou > "pages perso" des FAI: une URL disparait, l'herbergeur affiche autre chose, > comme il lui plait... > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
