Wikipédia:Bot/Requêtes/2023/06

État des requêtes

{{Requête en cours}}

{{Requête fait}}

{{Requête refus}}

{{Requête info}}

{{Requête pause}}

{{Requête stop}}

{{Requête sursis}}

{{Requête perdue}}

{{Requête caduque}}

{{Requête sans suite}}

Mois	02	03	04	05	06	07	08	09	10
Archives	02	03	04	05	06	07	08	09	10

Corrections dans le paramètre site des sources

Demande du 21 juin 2023, par : Wyslijp16 (discuter) 21 juin 2023 à 19:34 (CEST)

Références ou discussions / décisions justifiant la demande :

• Wikipédia:Le_Bistro/15_juin_2023#«_site=http:_»

Nature de la demande et discussion éventuelle :
Au niveau des sources, dans le paramètre site, il y a des « http:// » ou des « https:// », ce qui en fait des liens externes. Pourtant ce paramètre ne devrait pas contenir de liens externes (contrairement au paramètre url). Il faudrait donc retirer les http/https afin que les liens externes deviennent du simple texte ou des liens internes.

Simplifié par @Irønie que je remercie énormément : « Un bot pourrait bêtement retirer le "https" et les trucs après "/". Exemple "https://fu.bar.com/machin" -> "fu.bar.com" ».

En effectuant une simple recherche (insource:/site=http:/) je trouve déjà 11 462 résultats. Et une autre recherche (insource:/site=https:/) en affiche 9 758. Donc plus de 21000 articles avec cette erreur !

Une très grosse proportion de ces liens correspond à des objets célestes et est insérée sous la forme site=le [https://ssd.jpl.nasa.gov site du Jet Propulsion Laboratory] [1]. Escargot (discuter) 23 octobre 2023 à 23:18 (CEST)

Bonjour @Wyslijp16
Je viens de lancer mon bot. Je profite de ce passage pour ajouter des brisé le sur les liens web en erreur 404 et des points en fin de référence. Pour l'instant, je traite uniquement les http / https qui ne sont pas placés entre crochets. Escargot (discuter) 24 octobre 2023 à 18:09 (CEST)

Au passage, je me demande si pour les liens vers Google Maps il ne faudrait pas laisser google.com/maps plutôt que juste google.com Escargot (discuter) 24 octobre 2023 à 18:10 (CEST)

Auriez-vous un exemple précis de liens ? Si google.com fait une redirection vers google.com/maps, ce serait en effet très bénéfique (même si je ne pense pas qu'il y ait beaucoup de liens vers Google Maps dans les sources) ! Wyslijp16 (discuter) 24 octobre 2023 à 18:16 (CEST)

Bonjour Escargot bleu , merci beaucoup et à votre bot de vous occuper de ma requête !

J’espère que cela pourra améliorer les sources de tous les articles, malgré la complexité du problème. Wyslijp16 (discuter) 24 octobre 2023 à 18:14 (CEST)

En regardant un peu la liste du lien (et la multitude de site=le [https://ssd.jpl.nasa.gov site du Jet Propulsion Laboratory]), je me dis qu'on pourrait simplement le remplacer par site=[[Jet Propulsion Laboratory]] non ? Wyslijp16 (discuter) 24 octobre 2023 à 18:19 (CEST)

Tous ces articles ont été créé automatiquement par @Roland45. Je ne sais pas si il y a une raison à ce choix de mise en forme. Escargot (discuter) 24 octobre 2023 à 21:27 (CEST)

Bonjour, Je signale un problème : sur l'article https://fr.wikipedia.org/w/index.php?title=Isotta_Fraschini_Tipo_6_LMH-C&diff=prev&oldid=209261776, le robot a mis en rouge une mulititude de liens vers fr.motorsport.com, alors que les liens ne sont pas brisés. Chrisalmon (discuter) 2 novembre 2023 à 11:03 (CET)

Le site renvoie des codes 404 sur des liens qui sont effectivement fonctionnels. J'ai coupé le bot pour le moment, je regarderai plus tard. Escargot (discuter) 2 novembre 2023 à 12:17 (CET)

Je viens de relancer le bot.

Parmi les (rares) sites qui renvoient un code erreur erroné quand on leur demande les entêtes (requests.head en Python), la plupart renvoient le bon code en demandant le code de la page (requests.get). Dans mon nouveau code, je commence par demander les entêtes, puis fait un get en cas de code 301 ou 404. Le problème à demander tout le code html est que la requête est plus lourde, ce qui ralentit le bot et charge les serveurs de Wikimedia Cloud Service sur les pages avec beaucoup de liens brisés (quand la charge devient trop importante, le bot se fait kill automatiquement). Escargot (discuter) 19 novembre 2023 à 14:33 (CET)

 Escargot bleu : Y'a de vieux serveurs web qui n'acceptent pas les requêtes HEAD et renvoient donc une erreur. Donc le résultat négatif d'un HEAD n'est probablement pas suffisant pour qualifier un lien comme mort. :'( - Irønie (d) 19 novembre 2023 à 15:37 (CET)

Si tu crawl en masse divers sites pour vérifier les liens morts, fais gaffe aux bans d'IP ; Youtube, Google Search… Si t'utilises IP Wikimedia Cloud ça impacterait d'autres tools. (CodexBot se cache derrière Tor) Irønie (d) 19 novembre 2023 à 15:46 (CET)

En fait, le script tourne actuellement sur mon ordinateur, en faisant uniquement des get parce que je n'arrive pas à mettre un timeout sur les liens comme [2] trop lourds à charger (et qui se font kill sur WCS). Le paramètre timeout du module requests ne change rien et les solutions avec le module signal [3] arrêtent totalement le bot (mais peut-être que je fais mal quelque chose). Escargot (discuter) 19 novembre 2023 à 16:32 (CET)

Je ne maitrise pas Python, mais d'après la doc request:timeouts, .get() a 2 timeouts (connection+read) et pour read c'est le temps max avant de recevoir le premier byte. Avec le commentaire "(Specifically, it’s the number of seconds that the client will wait between bytes sent from the server. In 99.9% of cases, this is the time before the server sends the first byte)". A savoir qu'un gros fichier est envoyé en plein de paquets, ce que je crois comprendre c'est que ce time-out ne coupe pas la request HTTP, si elle fonctionne mais que le download de la page/fichier dure 10 minutes...

J'imagine qu'il faut trouver un module plus sophistiqué ou bien une manière d'intégrer le get() dans une fonction chronométrée (Signal pour Unix).

Bon courage. Have fun ! :) - Irønie (d) 19 novembre 2023 à 17:58 (CET)

J'ai réussi à le faire avec signal.

@Irønie en faisant des get à chaque fois, mon antivirus s'est réveillé à plusieurs reprises. Je suppose que je ne risque pas grand chose puisque les scripts ne sont pas exécutés, mais est-ce que tu appliques un traitement particulier avec CodexBot pour gérer les liens compromis ? Escargot (discuter) 28 novembre 2023 à 10:52 (CET)

@Escargot bleu Hou ! Non, je ne check pas les virus. J'y avais même jamais pensé ! Faudrait trouver une API antivirus GRATUITE !... Côté Google Web risk API, services ? A moins d'un service gratuit/rapide, j'ai peu d'espoir.

Par contre, j'étudie la gestion des nom de domaine usurpés (cybersquatting): une liste de domaines avec le bot qui passera les liens en {lien brisé}. Inspiré par ce qui se fait sur enwiki. Et création d'une page WP qui permettra de signaler de nouveaux domaines usurpés. -> Si cette tâche t'intéresse, voir en:WP:USURPURL, en:WP:Link rot/Usurpations et le bot en:WP:WAYBACKMEDIC.

- (dispo sur Discord pour talk tech) Irønie (d) 28 novembre 2023 à 11:29 (CET)

Après recherche rapide, je trouve en solution : 1) (lourd) installation d'un antivirus et traitement du contenu HTML des pages. Par exemple Clam sur linux. 2) facile ? l'API Google URL blocklisting (équivalent gratuit à Google Web Risk $$), avec envoi de batch de 500 url. Google API Safe browsing. Faudrait voir sur enwiki s'ils font du traitement automatique (au-delà de la spamlist). -- Irønie (d) 28 novembre 2023 à 12:24 (CET)

 Escargot mécanique et Escargot bleu : Bonjour ! Dans ce diff, le bot n'enlève pas seulement les "http(s)" mais aussi les "www.", ce n'est pas souhaitable. Peut-on revenir dessus ? Cordialement. Artvill (discuter) 3 décembre 2023 à 22:15 (CET)

@Artvill Les trois w ne font pas partie du nom du site, pourquoi vouloir les conserver ? On peut aussi bien accéder à un site sans qu'avec, ils rendent seulement le nom de domaine moins lisible. Escargot (discuter) 3 décembre 2023 à 22:32 (CET)

 Escargot bleuEh bien, tous les sites n'en ont pas, comme https://fr.wikipedia.org/ donc si les rédacteurs ont choisi de les conserver, ce n'est pas à supprimer. Cordialement. Artvill (discuter) 3 décembre 2023 à 22:39 (CET)

C'est différent dans le cas des sous-domaines. Quand sous-domaine il y a, je n'y touche pas. Mais pour le domaine principal, https://www.wikipedia.org/ et https://wikipedia.org/ renvoient à la même chose. Le nom déposé pour un domaine est toujours le nom sans www. www est juste le sous-domaine par défaut, j'ai vraiment du mal à voir ce que ça apporte.

L'argument du choix des utilisateurs n'est pas forcément pertinent. En l'occurrence, un certain nombre de personnes ont également choisi de mettre des http/https, ce qui ne justifie pas de les laisser. Escargot (discuter) 3 décembre 2023 à 22:48 (CET)

En l'occurrence, le problème généré par les http(s) est la création d'un lien externe non souhaité. D'où cette requête. A priori, personne n'a demandé aussi de retirer les www. qui ne posent pas de problème. Donc je ne comprends pas comment et pourquoi ils ont été intégrés à la requête. Artvill (discuter) 4 décembre 2023 à 00:26 (CET)

@Artvill. Même avis que @Escargot bleu :

• le paramètre site est seulement destiné à l'information du lecteur. Donc le www est totalement inutiles ici, car il n'apporte aucune information supplémentaire à l'humain quant à l'identification sur site web (à l'identique de http). Souvent, la valeur de site est même remplacée par le nom du site, du genre « Facebook » sans détail du domaine Internet.
• Les "www" sont conservés dans le paramètre url qui génère l'hyperlien cliquable, donc la navigation est correcte.

- Irønie (d) 4 décembre 2023 à 16:33 (CET)

Bonjour Artvill  !

Merci beaucoup pour votre remarque ainsi que vos observations des modifications !

En effet, le www n'était pas dans la demande mais je suis d'accord avec l'avis d'@Irønie ; c'est le nom du site (et si possible son article) qui est demandé, pas son nom de domaine. C'est une information pour les lecteurs et non une information technique.

En tout cas, si quelqu'un pourrait le faire, je propose de remplacer le nom de domaine/le nom du site dans le paramètre site= par l'article au sujet du site (lorsqu'il existe). Wyslijp16 (discuter) 6 décembre 2023 à 14:31 (CET)

Suivi de la demande :
En cours, Escargot mécanique(d · c) dressé par Escargot bleu(d) travaille. (24 octobre 2023 à 18:09 (CEST))