他サイトへのコメント埋め込みでは、大文字小文字を区別する URL はサポートされていません

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

W3C の規格では、ホスト名を除く URL は大文字小文字を区別するとされています。混乱を招くかもしれませんが、既存の規格に従うことが最も理にかなっていると考えます。

「いいね!」 1

はい。私はファイル名の大小文字を区別することに関しては、一般的に厳格な立場です。ファイル名で大小文字を無視して、人々が愚かなことをするようにさせるような、ずぼらなオペレーティングシステムに対して、少なくとも30年間(少なくとも1995年頃、私がウェブアプリの開発を始めた頃で、その当時の愚かなMacが大小文字を区別しないファイルシステムを持っていた頃)から憤慨してきました。何があったのかはわかりません。午前9時43分だったので、私は完全に目覚めていて、コーヒーも飲んでいました。もしかしたら誰かが私のアカウントをハックして、私が書いたのかもしれませんね:wink:

でも、今は投稿を削除してこの記録を消すには遅すぎます。

どうやら、以前は大文字小文字を区別しないためにあるユーザーが問題に直面していた状況のようですが、今度はその逆ですね!ソフトウェア開発って面白い世界です!

@techAPJ 申し訳ありませんが、大文字小文字を区別しない部分を取り消していただけないでしょうか。技術的には許可されていますが、今は標準に準拠すべきだと考えます。

「いいね!」 9

はい、そのコミットを元に戻しました(https://github.com/discourse/discourse/commit/feff8b74252dafbc7d4881b9284699ea488bea89)。

「いいね!」 8