La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: Optix le 18 septembre 2022 à 14:47:26
-
Bonjour à tous,
Je vous présente un nouvel outil : Diagno6.net
https://diagno6.net/
Il est destiné à tester la bonne accessibilité de vos services en IPv6 avec notamment :
- les DNS ayant autorité, qui gèrent vos noms de domaines
- les MX, qui réceptionnent vos emails
- les serveurs web, qui accueillent vos visiteurs
L'outil se veut plus poussé que ip6.nl dans le sens où il teste si les services sont réellement accessibles, et non juste reporter l'IPv6 si renseignée. Car une erreur est vite arrivée : le service n'écoute pas en IPv6, ou il sert une page blanche, une erreur, etc. Ainsi, votre page d'accueil est téléchargée en IPv4 et IPv6 pour vérifier la cohérence. Et l'outil peut donner des conseils (si l'adressage est présent, comment activer l'écoute en IPv6 par ex).
Techniquement, ça tourne avec du Symfony (PHP), Bootstrap (CSS) et RabbitMQ (pour l'async).
Hébergé chez OrneTHD à Rombas (57) et NDD pris chez Gandi.
C'est en beta pour le moment. Si vous avez des suggestions/remarques/zéééézuper, n'hésitez pas !
Et vive le boeuf bourguignon !
Cédric.
-
Merci Optix pour tout le travail.
Petite précision (si c'est toujours ok pour Optix) : L'outil a pour vocation à être mis en ligne sur le site de l'Arcep, dans le cadre de la Task Force IPv6 : https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6/task-force-ipv6.html (sous réserve de problèmes juridiques).
N'hésitez pas à tester l'outil, à apporter des propositions pour l'améliorer.
-
L'outil se veut plus poussé que ip6.nl dans le sens où il teste si les services sont réellement accessibles, et non juste reporter l'IPv6 si renseignée.
plusieurs points:
- ca test une url ou un domaine ? la zone de requête commence par https:// mais on ne peut mettre certaines url complexes et le message d'erreur n'est pas affiché (y'a juste un ! rouge sans explication)..c'est un peu flou. Tout domaine n'a pas forcement un serveur web.
- la boite de saisie présuppose https donc on ne peut tester http et si on coupe/colle une url dedans ca ne marche si on enlève pas "https://" avant (= problème d'ergonomie). par exemple dois-je pouvoir tester un truc comme "https://bouygues.testdebit.info/10G/10G.iso" avec cet outil?
- si je mets une ipv4 dans la zone de saisie ca fait une erreur 500
- Je ferais attention à mettre ce genre d'outil en ligne si ce n'est pas le PC de l'utilisateur qui fait la requête http mais ton serveur. Faire un requête http de façon automatisé sur une adresse inconnu a la requête de n'importe qui sur Internet peut avoir des conséquences. il te faut un "disclaimer " légal , que tu consigne quel ip demande quoi tout en étant en regle avant le RGPD. Je recommanderai aussi d'ajouter un header dans la requête http avec des infos comme quoi ton site 'forward' une requête pour quelqu'un d'autre (comme un proxy fait). Comme ca t'es plus "couvert" et le site final connait l'ip d'origine de "l'humain" qui a fait la requete. Il faut aussi informer l'utilisateur que son IP va être communiqué au site web testé.
- Ce test est 'vu' depuis ton serveur ce qui n'est pas forcement un indicateur que ca marchera pour l'utilisateur aussi (son résolveur dns est différent, sa géoloc, les cdn, etc).
Je pense que la configuration DNS et le bon fonctionnement d'un serveur web sont 2 problématiques différentes. Le fait que le deuxième dépende en partie du 1er n'est qu'un petit aspect des choses. Je ne suis pas convaincu de mélanger les 2 mais c'est que mon avis. Il a déjà plein d'outils pour tester le bon fonctionnement des sites web.
-
Effectivement, j'ai été un peu surpris de constater que ce n'est pas votre connectivité IPv6 qui est testée (même si votre IPv6 est affichée en haut à droite), mais celle d'un site que vous rentrez (par défaut indiqué https://arcep.fr).
ARCEP : note 3/5 parce que ses MX n'ont pas de DNS en IPv6.
D'autre part, quand on veut recommencer un autre test, ce n'est pas possible, il me dit que j'ai déjà fait un test il y a moins de 5 mn.
-
En analysant les 1009 noms de domaines avec un suffixe .gouv.fr je n'en ai trouvé qu'un seul nom de domaine qui propose de l'IPv6 sur le nom de domaine racine et le nom de domaine racine avec le préfixe www.
Il me semble important de rajouter quatrième test supplémentaire, en plus de DNS, MX et domaine racine en https : le nom de domaine racine avec le préfixe www.
On aurait donc une notation sur 7 étoiles et non 5.
Exemples concrets :
- https://outremersolidaires.gouv.fr
- https://ira-lille.gouv.fr
=> IPv6 déclarée uniquement sur la racine, pas sur le www
- https://www.consultation-rua.gouv.fr
- https://www.pacte-entreprises.gouv.fr
=> IPv6 déclarée uniquement sur www, pas sur la racine
Dans le cas où on rentre un sous-domaine à tester, la solution serait de tester le domaine racine.
Tests à faire en fonction de ce qui est rentré dans l'outil :
- domaine.com => test de domaine.com et www.domaine.com
- www.domaine.com => test de www.domaine.com et domaine.com
- forum.domaine.com => test de forum.domaine.com et domaine.com
Par ailleurs l'outil qui vériifie si on a déja testé le domaien les 5 dernéire minutes ne semble pas considérer les sous-domines. Si je test lafibre.info puis ipv6.lafibre.info, il me dit "Vous avez déjà testé un site il y a 5 minutes."
-
C'est un bon début, sujet à améliorations.
Là tu testes un domaine tiers, un préalable serait d'essayer également le client (du type https://test-ipv6.com/ code source ouvert pour implémentation connexe).
En gros, pour l'ARCEP, ce serait, tu es "compliant IPv6" tu es en mesure de tester les autres sites et pas uniquement toutes les 5mn, sinon, t'attends un peu avant de lancer des demandes en cascade constamment.
Je rejoins les analyses précédentes, en ce qui concerne les domaines et sous-domaines, il se trouve que j'ai des domaines qui en https pointent vers certaines adresses et http vers d'autres, et ne sont pas en corrélation entre les domaines et adresses ( cela peu paraitre biscornu, mais il y a une raison).
-
Merci pour l'outil :)
En testant mon domaine dont le serveur remplit tous les critères, pas de surprise, tout a été correctement joint.
J'ai décelé un petit bug : quelqu'un a du tester sfr.fr mais sans le TLD, et j'ai cliqué dessus dans les statistiques comme ça m'intriguait. Ça reste indéfiniment là-dessus, il faudrait interdire l'absence de TLD.
En analysant les 1009 noms de domaines avec un suffixe .gouv.fr je n'en ai trouvé qu'un seul nom de domaine qui propose de l'IPv6 sur le nom de domaine racine et le nom de domaine racine avec le préfixe www.
Il me semble important de rajouter quatrième test supplémentaire, en plus de DNS, MX et domaine racine en https : le nom de domaine racine avec le préfixe www.
On aurait donc une notation sur 7 étoiles et non 5.
Exemples concrets :
- https://outremersolidaires.gouv.fr
- https://ira-lille.gouv.fr
=> IPv6 déclarée uniquement sur la racine, pas sur le www
- https://www.consultation-rua.gouv.fr
- https://www.pacte-entreprises.gouv.fr
=> IPv6 déclarée uniquement sur www, pas sur la racine
Ça aurait été une bonne idée de penser à mettre de l'IPv6 sur la racine puis faire des CNAME pour tous les sous-domaines qui se situent sur le meme serveur.
-
Je rajouterai que tester un site web ce n'est pas juste faire une requête http GET et vérifier que ca répond 200.
Ca c'est juste un indicateur qu'il y a un 'serveur' qui parle http a cette adresse.
Deja ca peut répondre 404 par exemple et être tout a fait valide aussi.
Et si ca répond 200 ce n'est pas forcement que ca fonctionne correctement, surtout en IPv6 ou il se peut que des sous-parties du site (images, scripts tiers, etc) soient sur d'autres domaines/sous-domaines qui ne fonctionnent pas en IPv6). Et Il est fréquent que le serveur web qui répond en IPv6 ne gere pas le site web en question (probleme de vhost,etc).
Un test simple est juste de faire un HEAD par exemple et indiquer si ca répond (mais 200 ou 500 ou 40x, n'est pas une information forcement utile a remonter). Encore que certains sites ignorent HEAD...
Attention aussi aux redirections (3xx), on peut très bien être redirigé vers un site en IPv4... du coup pour être pertinent, ton 'requêteur' devrait être "IPv6 only".
-
Effectivement, je pense qu'il faut enlever le https://. L'outil teste un domaine, pas un site. D'autre part, il faudrait afficher par défaut, comme dans le modèle l'IPv4 et l'IPv6 de celui qui se connecte, et je pense que ce serait une information intéressante de rajouter l'AS auxquelles elles appartiennent, et si possible le FAI qui correspond. Et les DNS et MX de cet AS (qui sont ceux du FAI en général), pour montrer s'ils sont accessibles en IPv6. Puis de donner la possibilité de tester un domaine particulier, et dans ce domaine, voir si www.domaine.tld est un site web, ce qui est souvent le cas par défaut.
-
La problématique c'est que des sites web ont déclaré un AAAA (IPv6) et l'IPv6 ne fonctionne pas (par exemple car le serveur a changé, ils ont changé la A, mais pas le AAAA)
- Depuis un client fixe, cela ne se voit pas : Le client basculera en IPv4 rapidement (fall back).
- Depuis un réseau mobile Orange, Bouygues ou SFR, il y a une plateforme d'optimisation qui répond à la place du serveur et le fall back IPv4 sera impossible vu que le client aura eu la réponse de la plateforme d'optimisation.
Il y a un sujet dédié : IPv6 fallback to IPv4 (https://lafibre.info/ipv6/ipv6-fallback-to-ipv4/).
Pour ces raisons, il semble intéressant de tester la connexion et d'attribuer un point en cas de réponse. Par contre, en cas d'absence de réponse en https, le test pourrait se poursuivre par un test http pour couvrir les cas où le site est en http.
Afficher le retour (200, 404, 301,...) est une information intéressant à afficher, même si cela ne change rien aux points. Je pense que même une réponse 404 sur l'IPv6 doit donner un point.
Je pense que c'est une bonne idée de tenter d'améliorer https://ip6.nl/
On pourrait aussi changer le système de points (7 points si ont test les sous-domaines) pour donner une note. Une note /10 ?
-
La problématique c'est que des sites web ont déclaré un AAAA (IPv6) et l'IPv6 ne fonctionne pas (par exemple car le serveur a changé, ils ont changé la A, mais pas le AAAA)
J'ai vu le cas souvent. Changement d'hébergeur ou de serveur. L'intervenant est incompétent en réseau. Le A est changé mais pas le AAAA. Du coup l'ipv6 fonctionnait encore sauf qu'elle pointait sur l'ancien serveur donc on avait une page Apache par défaut ou une erreur vhost (ou pire l'ancien site plus a jour...).
Donc attribuer un point par ce que ca répond en http a l'ipv6 ce n'est pas forcement un "bon indicateur" de bon fonctionnement. Un domaine peut avoir plus d'étoiles qu'un domaine qui n'a pas de web en IPv6 mais qui dans les faits il "fonctionne" mieux.
Et comme indiqué déjà, peu de site sont comme lafibre.info : ils ne dépendent pas d'un seul serveur ou d'un seule IPv6. La page principale fait souvent appelle a des ressources situées sur d'autres url.
par exemple (informations affichée par IPvFoo (https://github.com/pmarks-net/ipvfoo))
(https://i.imgur.com/sPmR7U1.png)
tu lui donne une "étoile en plus" pour son site web "compatible IPv6" ?
-
Comme tu dis, c'est un problème ces enregistrements AAAA non mis à jour. L'outil pourrait peut-être traiter le problème en le signalant ?
En https, la solution à ce problème serait peut-être de vérifier le certificat TLS envoyé : On vérifie en IPv6 le nom de domaine du certificat et le fait qu'il soit valide et identique à celui en IPv4.
En http, vérifier que la taille de la page / est identique entre IPv4 et IPv6 ?
-
Comme tu dis, c'est un problème ces enregistrements AAAA non mis à jour. L'outil pourrait peut-être traiter le problème en le signalant ?
En https, la solution à ce problème serait peut-être de vérifier le certificat TLS envoyé : On vérifie en IPv6 le nom de domaine du certificat et le fait qu'il soit valide et identique à celui en IPv4.
En http, vérifier que la taille de la page / est identique entre IPv4 et IPv6 ?
Non, et non.
L'ARCEP c'est ni le gendarme, ni le garage automobile, des sites web qui fonctionnent pas, ce n'est pas de son ressort.
Et ce n'est pas sa vocation non plus de mettre à disposition un outil qui restreints le champ des possibles.
Ta dernière proposition, restreint le contenu des pages à l'identique entre IPv4 et IPv6, je le fais pas ainsi, et je sais à peu prêt ce que je fais, et aucune envie que un outil vienne me dire que je ne fais pas bien, je fais ce que je veux !!
Je ne remets pas en cause que certains puissent "oublier" et laisser trainer des adresses qui pointent vers rien, mais c'est de leur responsabilité, pas de celui d'un outil de venir leur dire, qui plus est venant de l'ARCEP !!
-
L'ARCEP c'est ni le gendarme, ni le garage automobile, des sites web qui fonctionnent pas, ce n'est pas de son ressort.
Là la problématique, c'est des sites web qui fonctionnement en IPv4, mais pas en IPv6 alors qu'ils ont une IPv6 déclarée au niveau DNS.
Je jugeais que cela rentre dans les actions pour aider la transition vers IPv6.
Peut-être proposer deux modes de fonctionnement : un qui va tester le contenu et un qui ne teste pas le contenu ?
-
J'avais compris le bien fondé de la proposition, là n'est pas la question, c'est plus profond, laisser a responsabilité de leurs actes aux individus. C'est de leur ressort, leur responsabilité et surtout de leur Liberté.
Ils ont le droit, et peuvent se "tromper", cela fait partie de leur processus d'apprentissage, tant que cela n'a pas d'incidence grave.
Si tu veux redéfinir le périmètre fonctionnel de l'outil, encore faut il l'avoir définis une première fois.
A mon avis, l'évolution de l'outil devrait reprendre des fonctionnalités de plusieurs produits existants déjà, parmi ceux déjà cités.
L'arbitrage finira par être celui de Cédric, dans la mesure ou c'est lui qui le construit.
Cela dit, tant qu'à faire, regrouper, l'UI et les diverses fonctionnalités en un seul "produit" de tous les sites cités.
-
En http, vérifier que la taille de la page / est identique entre IPv4 et IPv6 ?
Sur lafibre.info, ca donnerait un échec aléatoire :
- utilisateurs en ligne, nouveaux sujets, ...
- numéro du port TCP en bas de page : typiquement 4 ou 5 chiffres
-
Sur lafibre.info, ca donnerait un échec aléatoire :
- utilisateurs en ligne, nouveaux sujets, ...
- numéro du port TCP en bas de page : typiquement 4 ou 5 chiffres
Pour cela, un diff entre les 2 et tu calcules le ratio de ressemblance
-
Si https est disponible, j'utilise le certificat pour comparer IPv4 et IPv6.
La comparaison de contenu n'est que pour les sites qui n'ont pas de https. Je me base sur le fait que les sites qui ne proposent pas de https en 2022 sont presque exclusivement des sites statiques.
-
Même sur un site qui propose du https, il faudrait comparer le http (qui est souvent une simple redirection vers https, donc statique).
Sinon la première visite après la saisie du nom de domaine pourrait ne pas fonctionner.
Certes, un site bien IPv4 + IPv6 en https, mais qui n'a que l'un des deux fonctionnel en http, ça ne doit pas être courant.
-
Si le site répond sur le port 443, comparer le certificat TLS surtout le fait que le nom de domaine et date d'émission est identique entre la requête IPv4 et la requête IPv6 me semble suffisant.
Aller voir le contenu du site en http peut poser un problème si le site est dynamique et qu'il n'a pas de redirection vers https. On voit que malheureusement de nombreux sites https n'ont pas de redirection http vers https.
-
Merci Optix pour tout le travail.
Petite précision (si c'est toujours ok pour Optix)
OUIIIIIII !!!! <3 <3 <3
plusieurs points:
- ca test une url ou un domaine ? la zone de requête commence par https:// mais on ne peut mettre certaines url complexes et le message d'erreur n'est pas affiché (y'a juste un ! rouge sans explication)..c'est un peu flou. Tout domaine n'a pas forcement un serveur web.
Ca teste un domaine.
J'ai viré le préfixe "https://" et mis le msg d'erreur (oublié de le mettre dans le template).
- si je mets une ipv4 dans la zone de saisie ca fait une erreur 500
Fixé.
Je check aussi si le domaine est valide à présent (comme le bug remonté par Paul).
Assez content aussi de mon p'tit worker qui teste ça en arrière-plan : il ne plante pas la file d'attente si un site ne passe pas. Du coup les tests suivants ont pu aboutir sans intervention de ma part.
Je ferais attention à mettre ce genre d'outil en ligne si ce n'est pas le PC de l'utilisateur qui fait la requête http mais ton serveur. Faire un requête http de façon automatisé sur une adresse inconnu a la requête de n'importe qui sur Internet peut avoir des conséquences. il te faut un "disclaimer " légal , que tu consigne quel ip demande quoi tout en étant en regle avant le RGPD. Je recommanderai aussi d'ajouter un header dans la requête http avec des infos comme quoi ton site 'forward' une requête pour quelqu'un d'autre (comme un proxy fait). Comme ca t'es plus "couvert" et le site final connait l'ip d'origine de "l'humain" qui a fait la requete. Il faut aussi informer l'utilisateur que son IP va être communiqué au site web testé.
J'ai rajouté le "X-Forwarded-For" dans mes requêtes clientes.
Ce test est 'vu' depuis ton serveur ce qui n'est pas forcement un indicateur que ca marchera pour l'utilisateur aussi (son résolveur dns est différent, sa géoloc, les cdn, etc).
Ca, je n'y peux pas grand chose. Normalement il faut que ça marche dans toutes les situations aussi bien de mon point de vue que de celui de l'utilisateur.
D'autre part, quand on veut recommencer un autre test, ce n'est pas possible, il me dit que j'ai déjà fait un test il y a moins de 5 mn.
Oui j'ai mis un ratelimit sur l'IP cliente (quel que soit le site testé) et sur le domaine testé (quel que soit l'IP) pour éviter les abus.
Deja ca peut répondre 404 par exemple et être tout a fait valide aussi.
Je teste le code retour aussi. Si c'est un 4xx ou 5xx, ça ne donne pas l'étoile.
Le but c'est d'avoir un service en IPv6 qui fonctionne, pas qui renvoie une erreur à l'utilisateur.
***
Merci pour tous ces retours, très très constructifs ! Je m'attendais à 2-3 posts tout au plus (vu qu'avec Vivien on a déjà écrémé en amont) :D
Je traite la suite demain au fur et à mesure. ;)
-
Un même client ne peut pas tester plus d'un site par tranche de 5 minutes ?
J'ai le message "Vous avez déjà testé un site il y a 5 minutes."
Je pense qu'on peut facilement autoriser un client (une IPv4 ou /64 en IPv6) à tester 100 noms de domaines sur un intervalle de 30 minutes, cela ne me semble pas incohérent (ip6.nl permet même plus pour l'avoir fortement utilisé avec des listes de nom de domaines, car c'est le moyen le plus rapide de vérifier rapidement une liste de nom de domaines).
Il faut bloquer les scripts qui font n'importe quoi avec des requêtes à la suite, mais là quelques dizaines de requêtes d'un client, c'est sans problème.
-
Je teste le code retour aussi. Si c'est un 4xx ou 5xx, ça ne donne pas l'étoile.
Le but c'est d'avoir un service en IPv6 qui fonctionne, pas qui renvoie une erreur à l'utilisateur.
Tu peux très bien avoir un 404 sur la racine d'un site web qui pour autant fonctionne parfaitement. Par exemple un serveur d'api.
https://api.google.com/
-
Oui, je pense qu'il ne faut pas se focaliser sur le code qui est le code pour la racine et que le service n'est peut-être pas à la racine du site.
Renvoyer le message dans l'interface pour information est quand un plus de l'outil (même si cela ne rentre pas dans la note).
S'il est possible de donner des informations sur le certificat TLS (autorité qui a émis le certificat, nom de domaine et date d'expiration) cela pourrait être un plus. Notamment si ces informations sont récupérées pour vérifier que c'est les mêmes entre IPv4 et IPv6 on peut profiter pour les afficher.
-
y'a aussi des sites web qui refusent/filtrent les connexions venant d'un datacenter ce qui va être le cas avec ce type d'outil. Tu aura donc un 403 par exemple alors que le site fonctionne parfaitement bien.
on a eu le souci au début de Freepro: https://github.com/LaFibre-info/Freepro/issues/15
A mon avis et pour éviter d'être trop intrusif, je pense que plutôt qu'un 'GET' ou même un 'HEAD' il faut juste faire un 'dial tls' (tant pis pour HTTP ce n'est pas primordial de nos jours). ALPN si présent donne l'info si y'a un site web.
C'est plus simple et plus rapide au niveau backend et ca ne laisse quasi pas de traces. Tu peux récupérer le certificat TLS, check l'objet et comparer son fingerprint SHA entre IPv4 et IPv6 quand y'a les 2 et résume les infos ALPN.
apres pour être complet il faut aussi peut-être regarder en UDP a cause du HTTP/3 qui va être de plus en plus fréquent et de plus en plus le 1er choix via ALPN et/ou DNS (voir https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ )
-
Petite erreur de français :)
Ne pas être apparaitre publiquement dans les stats.
-
Félicitations pour l'initiative cela va être bien utile :D
Par contre je confirme, la limite de 1 domaine/5 minutes est beaucoup trop restrictive, surtout si l'on possède plusieurs domaines...
-
T'as un soucis, tu vois arriver que l'IPv4 dans statistiques ?
-
L'outil devrait, une fois finalisé, être sur le nom de domaine https://ipv6.arcep.fr
Merci Cédric.
-
Ah, on me dis dans l'oreillette que le renouvellement automatique du certificat n'est pas en place sur le domaine ;)
-
C'est réglé merci !
Le crontab avait fait son travail, mais nginx n'a jamais été reload avec, bizarre.
2022-12-30 07:18:45,993:DEBUG:certbot.display.util:Notifying user:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2022-12-30 07:18:45,993:DEBUG:certbot.display.util:Notifying user: The following certificates are not due for renewal yet:
2022-12-30 07:18:45,993:DEBUG:certbot.display.util:Notifying user: /etc/letsencrypt/live/diagno6.net/fullchain.pem expires on 2023-02-14 (skipped)
2022-12-30 07:18:45,994:DEBUG:certbot.display.util:Notifying user: No renewals were attempted.
2022-12-30 07:18:45,994:DEBUG:certbot.display.util:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
Hello,
Le site Web ne trouve pas certains domaines...
Je ne saurais dire pourquoi.
Certains de mes sous-domaines sont trouvés par le site, et d'autres sont considérés comme inconnus.
-
Hello,
Le site Web ne trouve pas certains domaines...
Je ne saurais dire pourquoi.
Certains de mes sous-domaines sont trouvés par le site, et d'autres sont considérés comme inconnus.
Balance :)
ou en privé comme tu veux.
-
Balance :)
ou en privé comme tu veux.
J'ai envoyé un MP.
-
Quand je teste http://www.patrick-chaize.fr/ j'ai :
Le domaine "www.patrick-chaize.fr" n'existe pas.
C'est lié au fait que le nom de domaine ne propose pas de https ?
-
Quand je teste http://www.patrick-chaize.fr/ j'ai :
Le domaine "www.patrick-chaize.fr" n'existe pas.
C'est lié au fait que le nom de domaine ne propose pas de https ?
Ok j'ai compris, le validateur du champ vérifie la présence d'un record SOA. C'est réglé désormais.
J'ai aussi corrigé :
- l'erreur de typo sur la page d'accueil "ne pas appaitre être publiquement dans les stats"
- l'erreur de % sur les stats pour le graph HTTP(S)
Merci !
-
Merci,
Cela serait possible que si on rentre une URL http:// ou https:// il supprime ce préfixe pour que cela puisse fonctionner ?
De même, si on entre qq chose après le nom de domaine, le / et tout ce qui est après est supprimé.