【发布时间】：2023-03-23 16:10:01
【问题描述】：
我正在使用 .htaccess 向支持它的浏览器提供 webp 图像。
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.webp [T=image/webp,E=REQUEST_image]
Header append Vary Accept env=REQUEST_image
AddType image/webp .webp
Source: WebP images with htaccess
基本上，它的作用是从同一位置返回一个 .webp 图像，而不是请求的 jpg/png/gif，如果它存在且受支持的话。
这在 Chrome、Firefox、IE11、Edge 中运行良好...尚未测试 Safari。
但是，我的问题是，当我右键单击网站“另存为”时，它会自动选择 .jpg 版本。如果 .jpg 版本不存在，它会尝试保存整个 html。如果使用它，预期的行为是保存显示的 .webp 版本。奇怪的是，它确实会尝试将 .webp 保存在 Firefox 中，但当我在 Firefox 中使用页面信息（Windows 上的 ctrl+i）尝试相同的操作时，它会选择 .jpg。
这怎么可能？ 这有什么遗漏/错误吗？
我检查了显示的图像是一个实际的 webp，它是。内容类型和文件大小都与 webp 匹配。
【问题讨论】：
-
恐怕您正在研究当今操作系统中文件处理的众多无关紧要的方面之一。原因是“文件扩展名”的想法已经被认为是区分文件类型的聪明想法太久了。取而代之的是，这些天来，事情转向了指定的 mime 类型，但是您仍然到处都有这些老式的方法。遗留代码。因为它既便宜又好用（适用于 > 99% 的案例和用户），所以没有人真正关心。对于 MS-Windows 平台尤其如此。
-
@arkascha 我一开始也这么认为，但后来我做了一些测试。我可以在一定程度上确认 Chrome 并不太关心文件名，因为当我将请求的图像定向到图像脚本时（它返回了 webp，但没有相同的标题），那么“另存为”正确假设网页。所以唯一的区别是我在 Vary 标头中使用了 Accept-Encoding 而不是 Accept。我不是专家，但这是否意味着这是某种缓存问题？我再次尝试使用 htaccess 代码，但也将 Vary 标头更改为 Accept-Encoding，这也有效。
-
@arkascha 我可能应该做更多的测试，但至少证明它不仅考虑到 img 标签中的文件扩展名。澄清一下，我所有的测试都有 src="path/to/img.jpg"，并且接受它显示 webp，但尝试另存为 jpg，而接受编码它显示 webp 并尝试另存为 webp。跨度>
标签： html image apache .htaccess webp