Sur community.wanikani.com, l’ouverture de liens vers des sujets contenant du japonais dans l’URL complète ne fonctionne plus lorsqu’ils sont ouverts dans un nouvel onglet ou copiés-collés directement. Le clic sur le lien pour naviguer dans le même onglet fonctionne toujours.
Par exemple, ouvrir ce lien dans un nouvel onglet devrait rediriger vers
Si le lien correspond exactement, tout fonctionne correctement. Mais bien sûr, avec les renommages de sujets, ce n’est souvent pas le cas.
J’ai également essayé de reproduire le problème sur try.discourse.org, mais sur cette installation, les caractères japonais ne sont jamais ajoutés à l’URL, même s’ils sont inclus dans le titre du sujet. Je ne sais pas pourquoi c’est le cas, mais sans cela, je ne peux pas démontrer le bug là-bas.
soupir On dirait que c’est encore un bug de Chrome. Chez moi, ça fonctionne parfaitement sur Firefox et Edge. Étrangement, cela fonctionne la première fois dans une fenêtre de navigation privée, mais échoue à la deuxième tentative. Il en va de même après avoir vidé le cache et les cookies du site, puis redémarré mon ordinateur.
Chrome indique que l’erreur est due à un nombre trop important de redirections.
Pourriez-vous vérifier sur Chrome afin de confirmer s’il s’agit d’un problème général ou seulement dans mon cas ? Assurez-vous simplement de tenter d’ouvrir la page plusieurs fois, car la première tentative semble fonctionner sans problème. Merci beaucoup pour votre aide !
Toujours avec Chrome ? Je veux juste m’en assurer avant de leur signaler le problème. Je suppose que rien n’a changé récemment sur Discourse à ce sujet ? (Quoi qu’il en soit, ce serait probablement toujours un problème de Chrome, puisque cela se produit uniquement là-bas, même si quelque chose avait changé sur Discourse.)
Eh bien, oublions ça. Cela a recommencé aujourd’hui. Je ne sais pas comment cela a pu être résolu pendant un moment.
Puisque cela risque de prendre du temps, je serais ouvert à des solutions de contournement pour l’instant. J’ai mentionné dans le message d’origine que sur try (et j’ai vérifié ici sur meta également), les caractères japonais ne sont jamais ajoutés à l’URL, contournant ainsi efficacement ce problème. Est-ce un paramètre du site ou de la catégorie dont je pourrais discuter avec mon administrateur de site ? D’autres suggestions de solution de contournement en dehors de celle-ci ?
Ce bug n’existait pas avant les dernières mises à jour (la dernière fois que j’ai essayé de partager un lien remonte à environ deux semaines, et tout fonctionnait parfaitement).
J’ai creusé notre base de code et il semble que l’erreur soit assez simple, mais j’aimerais vérifier mes hypothèses.
Nous avons un paramètre de site nommé slug_generation_method qui doit être modifié de la valeur par défaut ascii à encoded pour déclencher ce bug. Lorsque vous modifiez ce paramètre de site, nous effaçons tous les slugs et les régénérons.
Ce que je ne comprends pas, c’est pourquoi, lorsque le paramètre de site est défini sur “encoded”, nous générons un slug comme ceci :
Le slug brut de la table est renvoyé dans l’en-tête Location de la réponse 301 lorsque le slug d’un sujet ne correspond pas, et selon moi, nous devrions y renvoyer une URL valide.
Oui, nous devrions nettoyer la méthode de génération d’identifiants pour les données encodées afin de réduire sa dépendance aux fonctionnalités magiques du navigateur.
Alors, dites-vous que l’URL elle-même afficherait la version encodée ? Ou simplement que la redirection le gérerait en interne en utilisant la version encodée ? Dans les deux cas, il serait génial que cela « fonctionne tout seul » sans dépendre des particularités des navigateurs.
Non, comme l’indique le sujet ouvert dans la catégorie bug ici
@sam, j’ai revu cela aujourd’hui et il y a deux approches possibles :
Stocker un slug encodé réel dans la colonne slug lorsque le paramètre de génération de slug est défini sur encoded. Créer une migration pour effacer tous les slugs actuels utilisant des slugs encodés afin qu’ils se régénèrent correctement au fil du temps.
Conserver le slug UTF-8 actuel et le corriger à la volée lors de son envoi dans un en-tête pour une redirection 301.
À mon avis, l’option 1 est « plus correcte » et rendra plus difficile le passage du slug brut à un client. Cependant, simplement corriger le générateur de slug ne suffisait pas, car les navigateurs reçoivent une URL encodée lors d’une redirection 301 mais la décryptent pour la requête suivante, ce qui fait échouer notre comparaison de slug et déclenche une nouvelle redirection. Cela signifie que je devrai également corriger la méthode de comparaison des slugs dans le contrôleur des sujets, et peut-être ailleurs.
