Question

我在这里有一个谜。问题本身现在已经解决了，但我仍然无法看到实际原因：在我们的图片共享网站上，我们最近在搜索结果中为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 +＆＃34; srcset＆＃34; + srcset的值）作为图像路径，这当然导致错误404.

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

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

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

你有解释吗？

Answer 1

浏览器绝对没有办法正常搞砸。 HTML解析器非常坚固，它们不会随机地为属性添加额外的字节。

这绝对是代理或其他一些MITM以某种方式搞砸了标记。我建议放入一些JS，快速检查页面上的所有src属性，并检查是否包含＆＃34; srcset＆＃34;，如果是，请尽可能多地记录关于UA或其他的信息，这样你就可以了试图找到它们之间的共性。

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

或者，由于这显然是通过HTTPS传递的，这降低了代理重写的可能性，因此它可能是一个行为不当的扩展。