Html 在 <script src="http://..."> 中用 // 替换 http:// 是否有效？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/550038/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it valid to replace http:// with // in a <script src="http://...">?
提问by Darryl Hein
I have the following element:
我有以下元素：
<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>
In this case the site is HTTPS, but the site may also be just HTTP. (The JS file is on another domain.) I'm wondering if it's valid to do the following for convenience sake:
在这种情况下，站点是 HTTPS，但站点也可能只是 HTTP。（JS 文件在另一个域中。）为了方便起见，我想知道执行以下操作是否有效：
<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>
I'm wondering if it's valid to remove the http:or https:?
我想知道删除http:orhttps:是否有效？
It seems to work everywhere I have tested, but are there any cases where it doesn't work?
它似乎在我测试过的任何地方都有效，但有没有它不起作用的情况？
采纳答案by Jeff
A relative URL without a scheme (http: or https:) is valid, per RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax", Section 4.2. If a client chokes on it, then it's the client's fault because they're not complying with the URI syntax specified in the RFC.
根据RFC 3986：“统一资源标识符 (URI)：通用语法”，第 4.2 节，没有方案（http: 或 https:）的相对 URL 是有效的。如果客户端因此窒息，则是客户端的错，因为它们不符合 RFC 中指定的 URI 语法。
Your example is valid and should work. I've used that relative URL method myself on heavily trafficked sites and have had zero complaints. Also, we test our sites in Firefox, Safari, IE6, IE7 and Opera. These browsers all understand that URL format.
你的例子是有效的，应该有效。我自己在流量大的网站上使用了这种相对 URL 方法，并且投诉为零。此外，我们还在 Firefox、Safari、IE6、IE7 和 Opera 中测试我们的网站。这些浏览器都理解这种 URL 格式。
回答by Andrew Moore
It is guaranteed to work in any mainstream browser (I'm not taking browsers with less than 0.05% market share into consideration). Heck, it works in Internet Explorer 3.0.
它保证可以在任何主流浏览器中运行（我不考虑市场份额低于 0.05% 的浏览器）。哎呀，它适用于 Internet Explorer 3.0。
RFC 3986defines a URI as composed of the following parts:
RFC 3986将 URI 定义为由以下部分组成：
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
When defining relative URIs (Section 5.2), you can omit any of those sections, always starting from the left. In pseudo-code, it looks like this:
在定义相对 URI（第 5.2 节）时，您可以省略任何这些部分，始终从左侧开始。在伪代码中，它看起来像这样：
result = ""
if defined(scheme) then
append scheme to result;
append ":" to result;
endif;
if defined(authority) then
append "//" to result;
append authority to result;
endif;
append path to result;
if defined(query) then
append "?" to result;
append query to result;
endif;
if defined(fragment) then
append "#" to result;
append fragment to result;
endif;
return result;
The URI you are describing is a scheme-less relative URI.
您所描述的 URI 是无方案的相对 URI。
回答by Thilo
are there any cases where it doesn't work?
有没有它不起作用的情况？
If the parent page was loaded from file://, then it probably does not work (it will try to get file://cdn.example.com/js_file.js, which of course you could provide locally as well).
如果父页面是从 加载的file://，那么它可能不起作用（它会尝试获取file://cdn.example.com/js_file.js，当然您也可以在本地提供）。
回答by SLaks
Many people call this a Protocol Relative URL.
许多人称其为协议相对 URL。
回答by kennytm
Here I duplicate the answer in Hidden features of HTML:
在这里，我复制了HTML 隐藏功能中的答案：
Using a protocol-independent absolute path:
<img src="//domain.com/img/logo.png"/>If the browser is viewing an page in SSL through HTTPS, then it'll request that asset with the https protocol, otherwise it'll request it with HTTP.
This prevents that awful "This Page Contains Both Secure and Non-Secure Items" error message in IE, keeping all your asset requests within the same protocol.
Caveat: When used on a
<link>or @import for a stylesheet, IE7 and IE8 download the file twice. All other uses, however, are just fine.
使用独立于协议的绝对路径：
<img src="//domain.com/img/logo.png"/>如果浏览器正在通过 HTTPS 查看 SSL 页面，那么它将使用 https 协议请求该资产，否则它将使用 HTTP 请求它。
这可以防止 IE 中出现可怕的“此页面包含安全和非安全项目”错误消息，将所有资产请求保持在同一协议中。
警告：当在
<link>样式表的a或 @import 上使用时，IE7 和 IE8 会 下载文件两次。但是，所有其他用途都很好。
回答by Ned Batchelder
It is perfectly valid to leave off the protocol. The URL spec has been very clear about this for years, and I've yet to find a browser that doesn't understand it. I don't know why this technique isn't better known; it's the perfect solution to the thorny problem of crossing HTTP/HTTPS boundaries. More here: Http-https transitions and relative URLs
放弃协议是完全有效的。多年来，URL 规范对此非常清楚，我还没有找到不理解它的浏览器。我不知道为什么这种技术不为人所知；它是跨越 HTTP/HTTPS 边界的棘手问题的完美解决方案。更多信息：Http-https 转换和相对 URL
回答by bg17aw
are there any cases where it doesn't work?
有没有它不起作用的情况？
Just to throw this in the mix, if you are developing on a local server, it might not work. You need to specify a scheme, otherwise the browser may assume that src="//cdn.example.com/js_file.js"is src="file://cdn.example.com/js_file.js", which will break since you're not hosting this resource locally.
只是为了将其混为一谈，如果您在本地服务器上开发，它可能无法正常工作。您需要指定一个方案，否则浏览器可能会假定src="//cdn.example.com/js_file.js"为src="file://cdn.example.com/js_file.js"，这将中断，因为您没有在本地托管此资源。
Microsoft Internet Explorer seem to be particularly sensitive to this, see this question: Not able to load jQuery in Internet Explorer on localhost (WAMP)
Microsoft Internet Explorer 似乎对此特别敏感，请参阅此问题：无法在 localhost (WAMP) 上的 Internet Explorer 中加载 jQuery
You would probably always try to find a solution that works on all your environments with the least amount of modifications needed.
您可能总是会尝试找到一种解决方案，只需进行最少的修改即可适用于您的所有环境。
The solution used by HTML5Boilerplateis to have a fallback when the resource is not loaded correctly, but that only works if you incorporate a check:
HTML5Boilerplate使用的解决方案是在资源未正确加载时进行回退，但只有在合并检查时才有效：
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>
UPDATE: HTML5Boilerplatenow uses <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.jsafter deciding to deprecate protocol relative URLs, see [here][3].
更新：HTML5Boilerplate现在<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js在决定弃用协议相对 URL 后使用，请参阅 [此处] [3]。
回答by Pablo Torrecilla
Following the gnud's reference, the RFC 3986 section 5.2says:
在 gnud 的参考之后，RFC 3986 第 5.2 节说：
If the scheme component is defined, indicating that the reference starts with a scheme name, then the reference is interpreted as an absolute URI and we are done. Otherwise, the reference URI's scheme is inherited from the base URI's scheme component.
如果定义了方案组件，表明引用以方案名称开头，则引用被解释为绝对 URI，我们就完成了。否则，引用 URI 的方案是从基本 URI 的方案组件继承的。
So //is correct :-)
所以//是正确的:-)
回答by jlovison
It is indeed correct, as other answers have stated. You should note though, that some web crawlers will set off 404s for these by requesting them on your server as if a local URL. (They disregard the double slash and treat it as a single slash).
正如其他答案所说，这确实是正确的。不过你应该注意，一些网络爬虫会通过在你的服务器上请求它们来触发 404，就像本地 URL 一样。（他们忽略双斜线并将其视为单斜线）。
You may want to set up a rule on your webserver to catch these and redirect them.
您可能希望在您的网络服务器上设置一个规则来捕获这些并重定向它们。
For example, with Nginx, you'd add something like:
例如，使用 Nginx，您可以添加如下内容：
location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
return 301 $scheme:/$redirect_domain/$redirect_path;
}
Do note though, that if you use periods in your URIs, you'll need to increase the specificity or it will end up redirecting those pages to nonexistent domains.
但请注意，如果您在 URI 中使用句点，则需要增加特异性，否则最终会将这些页面重定向到不存在的域。
Also, this is a rather massive regex to be running for each query -- in my opinion, it's worth punishing non-compliant browsers with 404s over a (slight) performance hit on the majority of compliant browsers.
此外，这是一个为每个查询运行的相当庞大的正则表达式——在我看来，通过对大多数兼容浏览器的（轻微）性能影响来惩罚不兼容的浏览器是值得的。
回答by gnud
Yes, this is documented in RFC 3986, section 5.2:
是的，这记录在RFC 3986 的第 5.2 节中：
(edit: Oops, my RFC reference was outdated).
（编辑：糟糕，我的 RFC 参考已过时）。
