重定向 <image> 标签后面的图像有什么影响？

Question

一些设置：

我们有一些公开的静态图片。但是，我们希望能够在图像标记中使用替代 URL 来引用这些图像。 因此，例如，我们有一个带有如下 URL 的图像：

http://server.com/images/2/1/account_number/public/assets/images/my_cool_image.jpg

并且，我们希望将其插入到我们的前端 html 中：

<img src="http://server.com/image/2/my_cool_image.jpg">

而不是

<img src="http://server.com/images/2/1/account_number/public/assets/images/my_cool_image.jpg">

我们提出的一个非常巧妙的解决方案是使用 301 重定向。现在，我们的测试已经呈现了一些非常简洁的结果（所有当前一代的浏览器都可以），但我想知道这种方法是否有我可能遗漏的警告。

编辑：澄清一下，我们想要使用这种方法的原因是我们还计划使用外部主机来提供资源，并且我们希望能够偶尔关闭它。所以，也许 中的 URL 是

http://client.com/image/3/cool_image.jpg

除了“默认”的访问方式

Answer 1

另一种不需要服务器往返的技术是使用您的 HTTP 服务器等效的 "rewrite engine"。这允许您在服务器配置中指定通过发送某个 other URL 的结果来满足对一个 URL 的请求。这比告诉浏览器“不，去那边看看”更有效。

Answer 2

一个可能的缺点可能是 SEO - 带有通用文件夹名称的长而复杂的文件名可能会阻碍更短/更快捷的 URL。

但主要问题是每个图像都会有一个额外的 HTTP 请求。一般来说，您应该尽量减少 HTTP 请求以提高性能。我认为您应该像其他人所说的那样在幕后将 URL 重写为更长的版本。

您不必用最终到达网址重写整个网址。如果你想要更多的灵活性，你可以像这样重写图像：

http://server.com/image/2/my_cool_image.jpg

改写为：

http://server.com/getImage?id=2&name=my_cool_image.jpg

然后“getImage”脚本将读取一个配置文件，或者在 server.com 上提供较长名称的文件，或者从 client.com 提供另一个。您只需访问服务器一次，并且服务器本身的开销很小，访问者不会注意到。

Answer 3

唯一真正的缺点是第二次 DNS 查找和计算重定向的少量服务器开销，这两者都会影响性能。否则我想不出这种技术有什么问题。