L'incorporamento di commenti in un altro sito non supporta URL sensibili alle maiuscole

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 Mi Piace

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

1 Mi Piace

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 Mi Piace

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 Mi Piace

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 Mi Piace

Gli standard W3 affermano che, ad eccezione dei nomi delle macchine, gli URL sono sensibili alle maiuscole e minuscole. Anche se può risultare confuso, credo che abbia più senso attenersi agli standard esistenti.

1 Mi Piace

Sì. Sono generalmente un purista quando si tratta di nomi di file con distinzione tra maiuscole e minuscole. Mi sono indignato da quasi tre decenni (o almeno dal 1995, quando ho iniziato a sviluppare applicazioni web e il Mac stupido aveva un file system senza distinzione tra maiuscole e minuscole) per i sistemi operativi che ignorano con disinvoltura la distinzione dei casi nei nomi dei file, costringendo le persone a fare cose stupide. Non so cosa sia successo. Erano le 9:43, quindi avrei dovuto essere ben sveglio e aver già bevuto il caffè. Forse qualcuno ha hackerato il mio account e ha scritto questo? :wink:

Ma ormai è passato troppo tempo perché io possa cancellare il post per eliminare la traccia di questo.

Sembra che questa sia una di quelle situazioni in cui un utente aveva precedentemente problemi a causa della sensibilità alle maiuscole, e ora è il contrario! Che mondo divertente è lo sviluppo software!

@techAPJ Mi dispiace doverlo chiedere, ma potresti annullare la parte relativa alla sensibilità alle maiuscole? Tecnicamente è consentito e penso che dovremmo attenerci agli standard in questo momento.

9 Mi Piace

Ok, ho annullato quell’commit.

8 Mi Piace