تضمين تعليق في موقع آخر لا يدعم عناوين URLs حساسة لحالة الأحرف

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 إعجابات

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

إعجاب واحد (1)

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 إعجابات

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 إعجابات

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 إعجابات

تقول معايير W3 إنه باستثناء أسماء الآلات، يجب أن تكون عناوين URLs حساسة لحالة الأحرف. وعلى الرغم من أن هذا قد يكون محيرًا، إلا أنني أعتقد أن الالتزام بالمعايير المتبعة هو الأنسب.

إعجاب واحد (1)

أجل. أنا بشكل عام متشدد جداً عندما يتعلق الأمر بأسماء الملفات التي تفرق بين الأحرف الكبيرة والصغيرة. لقد شعرت بالغضب تجاه أنظمة التشغيل التي تتجاهل بلامبالاة حالة الأحرف في أسماء الملفات وتسبب للناس في ارتكاب أحمق، وذلك لمدة ثلاثة عقود تقريباً (أو على الأقل منذ حوالي عام 1995 عندما بدأت في تطوير تطبيقات الويب، وكان لدى ماك القديم نظام ملفات لا يفرق بين الأحرف). لست متأكداً مما حدث. كان الوقت 9:43 صباحاً، لذا كان يجب أن أكون مستيقظاً تماماً ولدي حتى قهوة. ربما تم اختراق حسابي وكتب شخص ما ذلك؟ :wink:

لكن الآن مر وقت طويل جداً بالنسبة لي لحذف المنشور لإزالة سجل هذا الأمر.

يبدو أن هذه واحدة من تلك الحالات التي واجه فيها مستخدم سابقًا مشكلات بسبب عدم حساسية الأحرف، والآن العكس! ما عالم ممتع هو تطوير البرمجيات!

@techAPJ، أكره فعل ذلك، لكن هل يمكنك إعادة الجزء الخاص بعدم حساسية الأحرف؟ إنه مسموح به تقنيًا، وأعتقد أننا يجب أن نلتزم بالمعايير هنا الآن.

9 إعجابات

حسنًا، لقد أرجعت ذلك الالتزام.

8 إعجابات