如果浏览器支持它,是否可以使用mod_negotiation来提供webp图像,否则可以使用jpg？
例如,如果我链接到带有路径/ images/test的图像,如果UA知道webp,它会提供在/images/test.webp中找到的图像,否则为jpg？
我试过四处寻找,但似乎Chrome中的Accept标头至少看起来像Accept:*/*,而不是指定图像类型.
如果这不是这样做的,有人有任何其他建议吗？
我想保持我的web服务器的所有静态文件在本地压缩,并根据请求压缩或不压缩它们.
在这些问题的答案我怎么能预先压缩与Apache 2.X的mod_deflate模块文件吗？,接近,因为实际上通过启用MultiViews并使用正确的AddEncoding,我可以让Apache foo.tar.gz在我请求时从我的web服务器返回压缩文件foo.tar,并且它带有正确的Content-Encoding:标头.
但这仅在客户端包含Accept-Encoding: gzip在发送到服务器的标头中时才有效.OTOH如果客户端不支持gzip编码,我的服务器告诉我,foo.tar对我来说没有"可接受" .
如果我使用它,我可以让Apache在发送之前解压缩该tarball AddOutputFilter INFLATE tar.但是,如果我这样做,那么服务器也会在我请求时foo.tar.gz(或者当我指定我接受gzip编码时)解压缩内容,这显然是我不想要的.
那么当客户端不支持gzip内容编码时如何让Apache解压缩文件,而在其他情况下如何提供预压缩文件呢？
编辑:根据@ covener的建议,我尝试了以下方法:
AddEncoding x-gzip .gz .tgz
RemoveType application/x-gzip .gz .tgz
AddType application/x-tar .tgz
<Location /packages>
FilterDeclare smgunzip CONTENT_SET
FilterProvider smgunzip INFLATE req=Accept-Encoding !$gzip
FilterChain smgunzip
</Location>
[在这里使用Apache-2.2.22.]但结果实际上比前三行更糟糕:当我请求.tar.gz文件时,它现在返回而没有"Content-Encoding:",当我请求.tar文件时,我收到了tar.gz的内容(即仍然是压缩的),无论"Accept-Encoding:"标题如何,仍然没有"Content-Encoding:".