html - SVG堆栈， anchor 元素和HTTP提取

Question

我有一系列重叠的问题，最好将其交集为:

在什么情况下，URL中的#字符( anchor )会在<a href或<img src的上下文中触发HTTP提取？

通常，应:

http://foo.com/bar.html#1

和

http://foo.com/bar.html#2

需要两个不同的HTTP提取？我认为答案绝对应该是“否”。

更详细的信息:

引发此问题的情况是我第一次尝试使用 SVG stacking(一种可以将多个图标嵌入单个 svg文件中的技术)，因此仅需要一个HTTP请求。本质上，想法是将多个SVG图标放置在一个文件中，并使用CSS隐藏所有图标，但使用CSS :target选择器选择的图标除外。

然后，当您在HTML中编写 #元素时，可以使用URL中的 img字符选择一个单独的图标:

<img 
    src="stacked-icons.svg#icon3" 
    width="80" 
    height="60" 
    alt="SVG Stacked Image" 
/>

当我在Chrome上试用时，它可以完美运行。发出一个HTTP请求，并可以使用不同的 anchor /目标通过相同的 svg url显示多个图标。

但是，当我在Firefox(28)上尝试此操作时，通过控制台看到发出了多个HTTP请求-每个svg URL一个!所以我看到的是这样的:

GET http://myhost.com/img/stacked-icons.svg#icon1 
GET http://myhost.com/img/stacked-icons.svg#icon2 
GET http://myhost.com/img/stacked-icons.svg#icon3 
GET http://myhost.com/img/stacked-icons.svg#icon4
GET http://myhost.com/img/stacked-icons.svg#icon5

...这当然会打败使用SVG堆栈的目的。

Firefox是否有某些原因要为每个URL发出单独的HTTP请求，而不是像Chrome那样简单地获取 img/stacked-icons.svg？

这就引出了一个更广泛的问题:-哪些规则确定URL中的 #字符是否应触发HTTP请求？

Answer 1

这是Plunker中的一个演示，可以帮助您解决其中的一些问题

Plunker

stack.svg#circ

stack.svg#rect

URI具有几个基本组件:

协议(protocol)-确定如何发送请求

域-将请求发送到

的位置

位置-域

中的文件路径

片段-在

中查找文档的哪一部分

媒体片段URI

片段只是标识整个文件的一部分。

根据 Media Fragment URI spec的实现，对于浏览器来说，发送Fragment Identifier可能实际上是完全公平的游戏。考虑流式视频，其中一些已缓存在客户端上。如果请求是 /video.ogv#t=10,20，则服务器可以通过仅发送回相关部分/段/片段来节省空间。此外，如果媒体的适用部分已经在客户端上缓存，则浏览器可以防止往返。

考虑往返，而不是请求

当浏览器发出GET请求时，并不一定意味着它需要从服务器一直获取文件的全新副本。如果已经具有缓存版本，则可以立即回答该请求。

HTTP状态码

200 - OK-获取资源并从服务器返回

302 - Found-在高速缓存中找到资源，自从上次请求我们需要获取新副本以来，资源没有太多更改。

缓存已禁用

各种因素都会影响客户端是否执行缓存:发出请求的方式(F5-软刷新； Ctrl + R-硬刷新)，浏览器上的设置，向请求添加属性的任何开发工具以及服务器处理这些属性的方式。通常，当浏览器的开发人员工具打开时，它将自动禁用缓存，因此您可以轻松地测试对文件的更改。如果您尝试具体观察缓存行为，请确保没有任何干扰此设置的开发人员设置。

在跨浏览器比较请求时，为了帮助减轻开发人员工具用户界面之间的差异，应使用 fiddler之类的工具来检查实际的HTTP请求和通过网络发出的响应。我将为您展示简单的插件示例。页面加载时，应在同一堆叠的svg文件中请求两个不同的ID。

这是 side by side requests of the same test page in Chrome 39, FF 34, and IE 11:


启用缓存

但是我们想测试启用了缓存的普通客户端会发生什么。为此，请为每个浏览器更新您的开发工具，或转到fiddler和“规则”>“性能”>，然后取消选中“禁用缓存”。

现在，我们的请求应如下所示:


现在，所有文件都从本地缓存中返回，无论片段ID是什么

特定浏览器的开发人员工具可能会尝试出于您自己的利益显示片段ID，但 fiddler 应始终显示实际要求的最准确地址。我测试的每个浏览器都从请求中省略了地址的片段部分:

捆绑请求

有趣的是，chrome似乎足够聪明，可以阻止对同一资源的第二次请求，但是当片段是地址的一部分时，FF和IE无法做到这一点。对于SVG和PNG同样如此。因此，第一次请求页面时，每次实际使用SVG堆栈时，浏览器都会加载一个文件。此后，很高兴从缓存中获取该版本，但会损害新查看者的性能。

最终成绩

CON :第一次旅行-并非所有浏览器都完全支持SVG堆栈。每个实例发出一个请求。
PRO :第二次旅行-SVG资源将被适本地缓存

其他资源

simurai.com被广泛认为是使用SVG堆栈的第一个应用程序，并且本文解释了当前正在进行的一些浏览器限制

Sven Hofmann有一个很棒的article about SVG Stacks，它涵盖了一些实现模型。

如果您想 fork 它或试用示例

，则这是 source code in Github

这是official spec for Fragment Identifiers within SVG images

快速查看Browser Support for SVG Fragments

bug

通常，页面所请求的相同资源将被捆绑到一个满足所有请求元素的单个请求中。 Chrome似乎已经解决了这个问题，但是我已经为FF和IE打开了漏洞，有一天可以解决这个问题。

Chrome -突出显示此问题的very old bug似乎已针对Webkit解决。

Firefox -Bug Added Here

Internet Explorer -Bug Added Here