SVG堆叠,锚元素和HTTP提取

Question

我有一系列重叠的问题,最好的问题是:

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

通常,应该:

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

和

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

需要两个不同的HTTP提取？我认为答案肯定是否定的.

更具体的细节:

提示这个问题的情况是我第一次尝试使用SVG堆叠 - 这种技术可以将多个图标嵌入到单个svg文件中,因此只需要一个HTTP请求.本质上,我们的想法是您将多个SVG图标放在一个文件中,并使用CSS隐藏所有这些图标,但使用CSS :target选择器选择的除外.

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

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

当我在Chrome上试用它时,效果非常好.发出单个HTTP请求,并且可以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会为每个网址发出单独的HTTP请求,而不是img/stacked-icons.svg像Chrome一样只提取一次？

这导致了更广泛的问题 - 什么规则确定#URL中的字符是否应该触发HTTP请求？

Answer 1

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

• Plunker
• stack.svg#保监会
• stack.svg#RECT

URI有几个基本组件:

• 协议 - 确定如何发送请求
• 域 - 发送请求的位置
• 位置 - 域中的文件路径
• 片段 - 要查看的文档的哪一部分

媒体片段URI

片段只是识别整个文件的一部分.

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

想想圆形旅行,而不是请求

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

HTTP状态代码

• 200 - 确定 - 获取资源并从服务器返回
• 302 - Found - 找到缓存中的资源,自上次请求获取新副本以来,资源不足.

缓存已禁用

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

在跨浏览器比较请求时,为了帮助缓解开发人员工具UI之间的差异,您应该使用像fiddler这样的工具来检查通过网络传输的实际HTTP请求和响应.我将向您展示简单的plunker示例.当页面加载时,它应该在同一个堆叠的svg文件中请求两个不同的ID.

以下是Chrome 39,FF 34和IE 11中相同测试页面的并排请求:

缓存已启用

但我们想测试在启用缓存的普通客户端上会发生什么.要执行此操作,请更新每个浏览器的开发工具,或转到fiddler和Rules > Performance >并取消选中Disable Caching.

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

现在,无论片段ID如何,所有文件都从本地缓存返回

特定浏览器的开发人员工具可能会尝试显示片段ID以供您自己使用,但fiddler应始终显示实际请求的最准确地址.我测试的每个浏览器都省略了请求中地址的片段部分:

捆绑请求

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

最终得分

CON:First Trip - 并非所有浏览器都完全支持SVG Stacks.每个实例发出一个请求.
PRO:第二次旅行 - SVG资源将被适当缓存

其他资源

• simurai.com被广泛认为是第一个使用SVG堆栈的应用程序,文章解释了目前正在进行的一些浏览器限制
• Sven Hofmann有一篇关于SVG Stacks的精彩文章,介绍了一些实现模型.
• 这是Github中的源代码,如果你想分叉它或者使用样本
• 这是SVG图像中片段标识符的官方规范
• 快速浏览浏览器支持 SVG片段

错误

通常,为页面请求的相同资源将捆绑到单个请求中,该请求将满足所有请求元素.Chrome似乎已经解决了这个问题,但我已经为FF和IE打开了错误,有一天会解决这个问题.

• Chrome - 这个突出显示此问题的非常老的错误似乎已经解决了webkit.
• Firefox - 这里添加了Bug
• Internet Explorer - 此处添加了Bug