Embedding Discourse comments in another site does not support case-sensitive URLs.
Using the standard embedding instructions provided in the admin interface, under Customize > Embedding, the host site provides the discourseEmbedURL value. If providing case-sensitive URL paths, such as http://site.com/AAA and http://site.com/aaa, the same comment thread will be embedded in both pages.
The root of this issue is in the normalizeURL function in Discourse’s public/javascript/embed.js file, which currently reads:
function normalizeUrl(url) {
return url.toLowerCase().replace(/^https?(\:\/\/)?/, '');
}
I would argue there is no reason to lower case the URL provided. The URL is provided by the host application, which should be able to make decisions about what is considered a unique URL. Removing toLowerCase() should be a non-breaking change that will allow case-sensitive URLs to be supported properly.
function normalizeUrl(url) {
return url.replace(/^https?(\:\/\/)?/, '');
}
Yes, it is. I have case-sensitive identifiers in the URLs in the action directory site I run for my app (example).
In retrospect, I should probably not have used case-senstive IDs, but that’s water under the bridge - would be hard to change now. Used a generator similar to those used for URLs shorteners like bitly (which are also case-sensitive).
I’d agree this could be a problem if it were a case that the user had to enter these URLs, but since the embedding is done programmatically, it doesn’t seem necessary to downcast.
Les normes du W3 indiquent que, à l’exception des noms de machines, les URL sont sensibles à la casse. Bien que cela puisse prêter à confusion, je pense qu’il est plus logique de se conformer aux normes en vigueur.
Oui. Je suis généralement intransigeant en ce qui concerne les noms de fichiers sensibles à la casse. Je suis indigné depuis presque trois décennies (ou du moins depuis environ 1995, quand j’ai commencé à développer des applications web et que le Mac stupide avait un système de fichiers insensible à la casse) par les systèmes d’exploitation qui ignorent paresseusement la casse dans les noms de fichiers et poussent les gens à faire des bêtises. Je ne sais pas ce qui s’est passé. Il était 9 h 43, donc j’aurais dû être bien réveillé et avoir même bu mon café. Peut-être que quelqu’un a piraté mon compte et a écrit ça ?
Mais maintenant, il est trop tard pour que je supprime le message afin d’effacer la trace de cet incident.
Il semble que ce soit l’un de ces cas où un utilisateur avait auparavant des problèmes en raison de l’insensibilité à la casse, et maintenant c’est l’inverse ! Quel monde amusant que le développement logiciel !
@techAPJ Je déteste faire cela, mais pourrais-tu annuler la partie insensible à la casse ? C’est techniquement autorisé et je pense que nous devrions nous en tenir aux normes ici maintenant.
