0

我这里有个谜。这个问题本身现在已经解决了，但我仍然看不到真正的原因：在我们的图像共享网站 Pixabay上，我们最近在搜索结果中实现了标签的srcset属性。img你可以在这里看到它的实际效果：https ://pixabay.com/photos/

那里的典型img标签如下所示：

<img src="/image__180.jpg" srcset="/image__180.jpg 1x, /image__340.jpg 2x" alt="...">

它工作得非常好 - 大约 99% 的用户都使用它。但是，一些报告看到此屏幕截图中描述的问题：

在此处输入图像描述

页面上正确加载了大约 30-50 个图像，而其他图像则导致图像损坏。我们意识到，我们的 NGINX 日志包含一些这样的错误：

open() "/.../image__180.jpg" srcset="/image__180.jpg 1x, /image__340.jpg 2x" failed (2: No such file or directory)

显然，由于未知原因，客户端请求整个表达式（src的值+“srcset”的值+srcset的值）作为图像路径，这当然导致了错误404。

我们玩了一下并意识到，首先提供标签上的属性srcset然后解决问题。没有更多的错误日志，没有更多的投诉。srcimg

<img srcset="/image__180.jpg 1x, /image__340.jpg 2x" src="/image__180.jpg" alt="...">

我在网络上的任何地方都找不到有关此行为的任何报告。但我想了解更多。以下是在Pixabay上与几位用户报告该问题的讨论：https ://pixabay.com/en/forum/help-me-please-11/pixabay-technical-difficulties-1474/?pagi=2

你有解释吗？

4

1 回答 1

2

浏览器绝对没有办法正常解决这个问题。HTML 解析器是坚如磐石的，它们不会随机地为属性消耗额外的字节。

这绝对是一个代理或其他一些 MITM 以某种方式与标记搞砸了。我建议放入一些 JS 来快速检查页面上的所有 src 属性并检查是否包含“srcset”，如果是，则尽可能多地记录有关 UA 或其他内容的信息，以便您可以尝试找到共性它们之间。

怀疑它可能是一些奇怪的代理检查/重写源，使用正则表达式/image.*.jpg/并将其重写回 URL 转义。这将捕获从src图像开始到最终 .jpg 中的所有内容srcset，并转义它们之间的所有空格和引号，以便获得一个大src属性值。

或者，由于这显然是通过 HTTPS 传递的，这减少了代理重写的机会，因此它可能是一个表现不佳的扩展。

于 2015-12-17T18:50:59.237 回答