为什么 CSS 数据 URI 会被记录为 404 请求？答案

【问题标题】：Why would CSS data-URIs be logged as 404 requests?为什么 CSS 数据 URI 会被记录为 404 请求？
【发布时间】：2013-06-21 04:56:27
【问题描述】：

为了减少我们网站上的请求数量，我们使用 CSS 数据 URI，而不是链接到外部图像。出于某种原因，这些数据 URI 有时仍会被记录为针对我们服务器的 404 请求。为什么会发生这种情况？

随机细节：

我们正在使用Splunk进行跟踪
发生在多个数据 URI 上
在所有浏览器上发生
在我们网站的多个页面上
我们的 QA 无法重现该问题
以下是来自特定数据 URI 的结果
相关 CSS 文件 - (http://c.mfcreative.com/lib/tgn/combo.ashx?14/css/v1/main.css)
同一文件的未压缩版本 - (http://c.mfcreative.com/lib/tgn/combo.ashx?14/css/v1/main.css&minify=false 参见第 35 行

相关CSS：

body{background:#e2decd url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAGuCAIAAADeSvtRAAAAfUlEQVQ4y9WTzQ7AIAiD+fr+rzzYSeOWGP+z7MABwVJstYiQmf02zvP3yrk2442Gqvijb9LT34tJ7vVP5u/zTBzDP113n/eYCv3ec1IOLGjn1bu9+K0zQEad/4r/iMj8dvLfVqetfcsf5X6z/y7ieuVk/SU19wMesxMXQMANapSO6rYFQnIAAAAASUVORK5CYII=) repeat-x 0 0}

查询以查看我们所有的 404 错误（前 10 个 404 错误中有 5 个数据 URI）：

sourcetype=iis* host=prd*ssscdn* sc_status=404 | top 100 cs_uri_stem

生成下图的查询：

sourcetype=iis* host=prd*ssscdn* sc_status=404 cs_uri_stem="/lib/tgn/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAGuCAIAAADeSvtRAAAAfUlEQVQ4y9WTzQ7AIAiD+fr+rzzYSeOWGP+z7MABwVJstYiQmf02zvP3yrk2442Gqvijb9LT34tJ7vVP5u/zTBzDP113n/eYCv3ec1IOLGjn1bu9+K0zQEad/4r/iMj8dvLfVqetfcsf5X6z/y7ieuVk/SU19wMesxMXQMANapSO6rYFQnIAAAAASUVORK5CYII="

任何帮助/指导将不胜感激！

alt text http://www.jasonbuckboyer.com/playground/blah/data-uri-404-error1.png

【问题讨论】：

数据 uri 不会以 data: 而不是 lib/ 开头吗？
如果它与 url 重写有关，你应该过滤它不要被重写，无论是在服务器还是 Splunk 配置（我不知道如何设置）。我猜听起来很明显:)
我的一个客户也在非 IIS 服务器上看到了这一点。他们以 /lib/tgn/ 开头的原因是因为这是 CSS 文件的相对路径；如果他（？）将 CSS 放在他的根目录中，那么数据 URI 请求将遇到 /data:image/png[...]

标签： css request http-status-code-404 data-uri splunk

【解决方案1】：

我同意 Srikanth 的评论。在我看来，您的代码中有一些东西将/lib/tgn/ 附加到url 字符串的前面，最终将其放在data 之前以产生/lib/tgn/data:image/png，这是无效的。

如果它是数据 uri，您需要跟踪该代码并让它忽略所有字符串，同时仍然允许它将图像路径附加到在 /lib/tgn/ 目录中保存和访问的图像。

添加说明

根据您的评论，我不确定我们的沟通是否很清楚。我在上面发布的“生成下图的查询”代码中看到的是：

cs_uri_stem="/lib/tgn/data:image/png;base64,iVBORw0KGgo... [etc.]"

并且您发布的图像显示了cs_uri_stem 值都在data:image/png 之前插入了/lib/tgn/。 某些东西（可能是您的 CDN 组合，可能是您服务器上的 url 重写规则或其他东西）似乎导致 /lib/tgn/ 代码被添加到 进程中的 css url() 代码中/request time（因为它似乎没有被直接添加到 CSS 中，因为您的缩小或扩展代码均未显示它已添加）。但是您发布的图像显示的最终结果表明导致 404 错误的cs_uri_stem 都在data:image/png 之前添加了/lib/tgn/。因此浏览器最终不会将 url() 视为 data，因为请求以 path 开头，即/lib/tgn/data:image/png ...。因为它认为它正在寻找一个从路径/lib/tgn/ 开始的文件，所以浏览器发出了一个请求（当然）它永远不会得到满足，因此会生成 404 错误。

现在也许我还不清楚你在评论中指的是什么，但也许我已经更清楚了我认为你的问题是什么。

【讨论】：

我们的 CDN 自动合并和缩小文件。当它通过我们的组合器时，我们转到c.mfcreative.com/lib/tgn/combo.ashx?names-of-all-our-css-files。我已将上面的 URL 更新为在我们的生产环境中的使用方式。抱歉，最初应该这样做。
我不太确定我们是否正在就同一件事进行交流。我在回答中添加了进一步的解释，但我可能仍然误解了您打算在评论中澄清的一些内容。
在您的原始答案中，我认为您的意思是 /lib/tgn/ 已添加到实际的 CSS 文件中，但事实并非如此。我认为它与服务器端重写规则没有任何关系，因为它的行为就像任何其他相对包含的图像一样。但更大的问题是为什么它会被作为服务器端请求处理。就像浏览器没有将data:image/png;base64,iVBORw0... 识别为有效的数据URI，因此它正在向服务器发出请求......
嗯，我最初的答案很模糊，因为它似乎被添加到 somewhere （可能是在 CSS 中或其他地方）。您的评论暗示您确实有一个服务器重写规则来添加/lib/tgn/，对吗？如果是这样，那将解释为什么它会显示，但我同意它不会解释为什么要开始请求（只有将它添加到 CSS 中才会如此）。
@user1394692：还有两个想法。一个，另一篇在线帖子指出Google（以及理论上的其他搜索引擎）有时会做一些导致请求字符串“添加”的事情。二，您是否尝试将请求用引号括起来 (url('data: ...')) 以查看它是否偶然解决了问题（可能是数据字符串中的某些不正确转义的字符触发了它发出请求）？