Exemple avec https://matrix.to/#/#copie-publique:codelutin.com pour la dépêche https://linuxfr.org/news/copie-publique-des-entreprises-s-allient-pour-financer-les-communs-numeriques
Suivi — Dépêches Impossible de mettre un lien vers un salon matrix dans les liens d'une dépêche
31
déc.
2022
# Fragment
Posté par nud . Évalué à 2 (+0/-0).
J'imagine que le problème c'est le '#' ?
[^] # Re: Fragment
Posté par nud . Évalué à 3 (+0/-0).
Bon je n'étais pas loin, le problème c'est que la validation des liens considère que l'URL "https://matrix.to/#/#copie-publique:codelutin.com" n'est pas valide car elle contient deux fois le caractère
#
.[^] # Re: Fragment
Posté par nud . Évalué à 3 (+0/-0). Dernière modification le 05 janvier 2023 à 23:27.
Les liens dans les dépèches et dans les bookmarks sont validés comme suit et refuse l'URL matrix.to:
Le site web personnel de l'utilisateur est validé comme suit et accepte l'URL matrix.to:
Les bookmarks utilisent le même procédé pour indiquer que l'URL est mauvaise si la validation échoue:
Ça vaudrait peut-être la peine d'uniformiser tout ça. :-)
A priori ce
http_url
vient deapp/validators/http_url_validator.rb
, qui utiliseURI.parse
mais échoue:Donc ruby n'est pas capable de parser une URI que sa regexp considère comme valide…
[^] # Re: Fragment
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Je pense que le paramètre
allow_blank
fait toute la différence. Ce n'est pas le cas par défaut, où juste/#/
est vu comme aussi vide de sens que//
à cet emplacement.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fragment
Posté par nud . Évalué à 3 (+0/-0).
Non,
allow_blank
permet juste d'accepter une valeur vide, ce n'est pas passé àURI::regexp
. Ça valide juste parce que la regexp n'est pas ancrée. Tu peux mettre n'importe quoi et ça passe, tant que y'a une URL quelque part.C'est un bug qui mériterait d'être corrigé.
Par contre il est intéressant de constater que la RFC 3986 n'autorise pas de
#
dans le fragment (ce qui implique que l'URL de l'OP est invalide):La regexp retournée par
URI.regexp
est d'ailleurs correcte en ce sens:Pour rendre l'URL valide au sens de la RFC 3986 il faudrait donc encoder le
#
:Par ailleurs, python accepte l'URL telle quelle, avec les 2
#
(j'imagine que c'est une déviation de la RFC qui est assez courante et elle ne cause pas d'ambiguité en soi):[^] # Re: Fragment
Posté par nud . Évalué à 3 (+0/-0). Dernière modification le 06 janvier 2023 à 01:32.
Voir aussi ce bug report pour matrix.to: Switch to valid URL syntax #17
Correctif pour l'incohérence de validation: Fix validating the URL of user home sites #355
Faut pas laisser >trim dormir.
[^] # Re: Fragment
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Merci pour la MR. Il faudrait changer le message affiché par contre pour retirer "URL", qui ne parle qu'aux gens techniques. On a uniformisé avec "adresse" quand c'est pour les visiteurs.
[^] # Re: Fragment
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3 (+0/-0). Dernière modification le 06 janvier 2023 à 18:22.
Et >oumph non plus pour gérer les déploiements :)
Merci pour l’analyse, je conclurai donc que l’entrée de suivi ne sera pas corrigée: si Matrix a décidé de ne pas suivre le standard des URLs, ce n’est pas à LinuxFr à s’adapter.
Comme le lien peut être mis dans le texte de la dépêche, je propose de ne pas tordre le validateur.
Si je suis bien la discussion du côté de Matrix, des utilisateurs ont proposé des solutions techniquement juste, mais les mainteneurs n’ont pas réagi depuis 2017 et ont écarté certaines propositions juste parce qu’elles ne sont pas esthétiques.
Dans cette discussion, le second commentaire parle d’une autre forme de liens pour Matrix, les « compact URL » peuvent aussi aider à contourner ce problème.
[^] # Re: Fragment
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+0/-0).
J'ai rajouté le lien %-codé sur la dépêche https://linuxfr.org/news/copie-publique-des-entreprises-s-allient-pour-financer-les-communs-numeriques
J'étais persuadé que ça ne marchait pas… Donc soit j'ai un mauvais souvenir, soit il y avait un souci quand j'ai testé à l'époque… En tout cas on a un contournement (pas super sympa pour le lectorat qui doit apprendre à %-coder des URL) fonctionnel.
[^] # Re: Fragment
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Ah oui, il y a la possibilité d'encoder le dièse en pourcent pour garder des liens valides.
J'ai proposé un merge request ici pour faire ça automatiquement: https://github.com/linuxfrorg/linuxfr.org/pull/356
J'ai renommé le validateur de
http_url
versuri
simplement, parce qu'il est encore généraliste et pourrait être utilisé pour d'autres styles d'URI (commemailto:
,xmpp:
…).J'ai appris que Rails permet de définir des méthodes
before_validation
qui permettent de modifier les paramètres reçus dans le modèle avant de faire passer les validateurs.J'en ai profité pour fusionner le code existant déjà dupliqué entre
link
etbookmark
en plus d'ajouter l'encodage automatique des dièses.Il faudra adapter le code de Mastodon quand on aura fusionné cette MR.
[^] # Re: Fragment
Posté par nud . Évalué à 3 (+0/-0).
Je propose de d'abord merger les deux PR qui utilisent le validateur
http_url
avant de changer le nom.[^] # Re: Fragment
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Au passage on devrait valider les URL xmpp aussi, mais ça va poser souci.
Par exemple:
Il faudrait aussi convertir les 4976 champs vides en NULL probablement.
Sans parler de ceux en https://… ou sans '@' (45 de plus).
Et 3 en erreur sur le username qui contient ` ou â ou é.
Reste 721 entrées (non préfixées par xmpp: en base), qui sont valides selon URI.parse (avec ou sans le xmpp:).
Plus des questions annexes :
[^] # Re: Fragment
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Première réponse annexe : non…
Seconde réponse annexe : oui…
Accessoirement, je pense qu'il ne faut pas préfixer par xmpp
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fragment
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Bien vu pour l'ancrage. Et pour l'encodage du
#
.De ce que je comprends de la réponse de Python, le premier croisillon est bien vu comme marqueur d'ancre (fragment) et le second avec la barre (slash) qui précède font partie de l'ancre : ce n'est pas une déviation courante mais un laxisme qui se justifie dans son contexte (la commande ne valide pas par rapport au RFC mais découpe en composants au mieux)
Ça montre que l'encodage de caractère devrait se faire pour les deux croisillons pour éviter toute ambigüité…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Fragment
Posté par nud . Évalué à 2 (+0/-0).
Non, le premier "croisillon" correspond bien au séparateur du fragment et est géré comme tel par matrix.to. Ils justifient même cette entorse au RFC par le fait que le fragment n'est pas envoyé au serveur.
[^] # Re: Fragment
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Ah d'accord, j'avais cru que matrix gérait ça autrement. My bad.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.