15

現在実行中の JavaScript をロードしたページと同じスキーム (おそらく "http:" または "https:") で URL を構築したいと考えています。最新のブラウザーは、スキーム (たとえば、src="//example.com/test.js") の省略のみをサポートしていますが、これはブラウザー間の完全な互換性はありません。(IE 6 はそれをサポートしていない唯一のブラウザーであると読みましたが、それでもそのバージョンとの互換性が必要です。)

これを行うクロスブラウザの方法は、チェックすることのようlocation.protocolです。たとえば、Google アナリティクスでは以下を使用します。

('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + ...

Google の場合、要求が SSL を使用するかどうかに応じて異なるドメインを使用したかったため、そのパターンは理にかなっています。しかし、プロトコルだけが異なる場合でも、他の人が同じパターンを使用しているのを見てきました。

('https:' == location.protocol ? 'https:' : 'http:') + "//example.com"

(一例はhttp://css-tricks.com/thinking-async/の「Wufoo の最終スニペット」にあります。)

代わりに、このより単純な式を使用したいと思います。

location.protocol + "//example.com"

location.protocol自分が管理していないサイトで自分のコードが使用されている場合に、「https:」または「http:」以外の値が取得される可能性について本当に心配する必要がありますか?

4

3 に答える 3

14

常に何かに設定されますが、「http」でも「https」でもない値に設定される場合があります。あなたが目にする可能性が最も高い他の 3 つの値は、( file:HTML ファイルの場合)、about:(を含む iframe マジックの場合about:blank)、そしておそらくftp:.

于 2012-11-03T23:20:28.197 に答える
5

注:これは厳密に document.location.protocol の戻り値が有効かどうかということではなく、バグを見つけるのが非常に難しいことを示しています (JavaScript を書かなくても document.location.protocol の動作をオーバーライドできます)。

document.location.protocolが正常に機能していないように見える、一見奇妙なケースに遭遇しました。このサイトには、現在のプロトコルを解決するために次のスニペットを使用するトラッキング Javascript がありました。

var proto = ('https:' === document.location.protocol ? 'https://' : 'http://')

サイトは HTTPS を使用していましたが、一部のページでは、プロトコルが予想されるhttpsではなくhttpであることが判明しました。

グーグルで多くの時間を費やしてアプリケーションスタック構成を調査した後、ある開発者は、プロトコル解決の問題が発生するページに、次の属性を持つ HTML フォームがあることを発見しました。

name="location"

これにより、プロトコル解決が誤動作し、プロトコルが https ではなく http に誤って推定されました (いいえ、フォームには protocol と呼ばれるフィールドがなく、あるべきでもありませんでした)。

于 2014-05-05T07:16:09.833 に答える
2

私のコードが私が管理していないサイトで使用されている場合、document.location.protocol が「https:」または「http:」以外の値を取得する可能性について本当に心配する必要がありますか?

特にそうではありませんが、代わりに、アプローチに特に害はありません(プロトコルが何であれ、事前に保留されています)。Google アナリティクスは、他のものとは異なるホストを使用しているため、おそらく実際の検出を行っています。

于 2012-11-03T23:20:44.727 に答える