在另一个网站嵌入评论不支持区分大小写的 URL

贡献 错误
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 个赞
2

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

1 个赞
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 个赞
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 个赞
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 个赞
6

W3C 标准指出，除机器名称外，URL 应区分大小写。尽管这可能会造成混淆，但我认为遵循现有标准是最合理的选择。

1 个赞
7

是的。在文件名区分大小写这个问题上，我通常是个强硬派。对于那些懒惰地忽略文件名大小写、导致人们做出愚蠢行为的操作系统，我至少已经愤慨了快三十年了（或者说，至少从1995年我开始开发 Web 应用、那时愚蠢的 Mac 还使用不区分大小写的文件系统开始）。我不太清楚当时发生了什么。那是上午 9 点 43 分，我本该完全清醒，甚至已经喝过咖啡了。也许有人黑了我的账号并代我写了那段话？:wink:

但现在已经过去太久了，我无法再删除帖子来抹去这条记录。

11

看起来这是那种之前有用户因为不区分大小写而遇到问题，而现在情况却相反的情况！软件开发的世界真是有趣！

@techAPJ 我很抱歉提出这个请求，但能否请你将不区分大小写的部分回退？这在技术上是允许的，而且我认为我们现在应该坚持遵循相关标准。

9 个赞
13

好的，我已经回退了那个提交。

8 个赞