La incrustación de comentarios en otro sitio no admite URLs sensibles a mayúsculas y minúsculas

Contribuir Error
1

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?(\:\/\/)?/, '');
}

Thoughts?

3 Me gusta
2

I think that it’s confusing to people to have URLs that are case sensitive so it makes sense to downcase them.

1 me gusta
3

No, one should never assume that URL paths are case insensitive.

I suspect this was done because we had people having trouble embedding without the toLowerCase, @techAPJ?

@agiletortoise I presume you are raising this because this is actually causing a problem for you somewhere?

5 Me gusta
4

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.

4 Me gusta
5

eh, URL paths MUST be treated as case sensitive by external systems… just like email usernames, but that’s a story for another time

5 Me gusta
6

Los estándares del W3 indican que, excepto para los nombres de máquinas, las URL deben ser sensibles a las mayúsculas y minúsculas. Aunque puede resultar confuso, creo que tiene más sentido adherirse a los estándares existentes.

1 me gusta
7

Sí. En general, soy partidario de los nombres de archivo sensibles a mayúsculas y minúsculas. Me he sentido indignado con los sistemas operativos que ignoran de manera descuidada el caso en los nombres de archivo y hacen que la gente haga cosas estúpidas durante casi tres décadas (o al menos desde 1995, cuando empecé a desarrollar aplicaciones web y el estúpido Mac tenía un sistema de archivos insensible al caso). No estoy seguro de qué pasó. Eran las 9:43 a. m., así que debería haber estado totalmente despierto e incluso haber tomado café. ¿Quizás alguien hackeó mi cuenta y escribió eso? :wink:

Pero ahora ha pasado demasiado tiempo para que pueda eliminar la publicación y borrar el registro de esto.

11

Parece que esta es una de esas situaciones en las que un usuario tuvo problemas anteriormente debido a que no distinguía entre mayúsculas y minúsculas, ¡y ahora sucede lo contrario! ¡Qué divertido es el mundo del desarrollo de software!

@techAPJ No me gustaría tener que pedir esto, pero ¿podrías revertir la parte que no distingue entre mayúsculas y minúsculas? Técnicamente está permitido y creo que deberíamos ceñirnos a los estándares ahora.

9 Me gusta
13

Vale, he revertido ese commit.

8 Me gusta